No changes but some feedback.
https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.htmlFile doc/go_spec.html (right):
https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode820doc/go_spec.html:820: of type <code>int</code>.
On 2012/12/11 18:36:30, r wrote:
"representable by a value of type int" is sort of a category error. a
value is a
value; it's not representing anything. i think you mean stored in a
variable of
type int, but that sounds wrong, and the same glitch occurs elsewhere. you've
added a lot more instances of this, so let's clean it up everywhere.
since a type represents a range of values (we've used that idea when
introducing
types), how about just 'representable by an int'? or maybe 'in the
range of the
int type'?
I am fine with changing this, but:
a) what you are suggesting is close to what I had at first, and iant
objected;
b) we are using the current phrase "representable by a value of type T"
elsewhere fairly consistently (see Assignability, Conversions, Constant
expressions, etc.).
(The notions of "representable as a value of type int", "integer value",
"value of integer type", and "value of int type" are all very similar in
English, but they all mean different things in the spec. It's probably
worthwhile making the nomenclature clear in the spec at some point but
not in this CL).
https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840doc/go_spec.html:840: For instance, the maximum size of an array type
may be restricted by
On 2012/12/11 18:12:35, iant wrote:
But now you are back to not setting a lower bound. That was my original
complaint, and rsc mentioned it also.
quoting rsc: "I think it would be fine not to set a lower bound and
say..."
(what I have written now).
https://codereview.appspot.com/6903048/diff/18002/doc/go_spec.html#newcode840doc/go_spec.html:840: For instance, the maximum size of an array type
may be restricted by
On 2012/12/11 18:36:30, r wrote:
what is this clause trying to achieve, exactly? a compile-time
constraint? a
run-time-constraint? mere ass-covering?
It is a compile-time constraint currently implemented by 6g. The clause
is merely permitting an implementation to have such a constraint (rather
than having to resort to some other error - say out of memory, at
run-time). So yes, "ass-covering"...
https://codereview.appspot.com/6903048/