code review 142320043: spec: clarify variable declaration type rules

spec: clarify variable declaration type rules

Not a language change.

Several inaccuracies were fixed:

1) A variable declaration may declare more than just one
variable.

2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.

3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).

4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.

To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.

Fixes issue 8088.

[gri, 2014-09-19 23:12:27]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[r, 2014-09-19 23:19:12]

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1878
doc/go_spec.html:1878: A variable declaration creates one or multiple variables,
binds corresponding
s/multiple/more/

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1879
doc/go_spec.html:1879: identifiers to them, and gives each a type and optionally
a non-zero initial value.
zero should be a link

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1902
doc/go_spec.html:1902: with the expressions following the rules for <a
href="#Assignments">assignments</a>.
what rules? ordering?

the old text seems better here. this version doesn't explain the mapping from
expressions to identifiers

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1912
doc/go_spec.html:1912: identifier instead.
that's an odd way to say it. what does the blank identifier have to do with it?
again, the old text seems mostly better

[gri, 2014-09-19 23:28:50]

Request for more feedback.

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1878
doc/go_spec.html:1878: A variable declaration creates one or multiple variables,
binds corresponding
On 2014/09/19 23:19:12, r wrote:
> s/multiple/more/

Done.

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1879
doc/go_spec.html:1879: identifiers to them, and gives each a type and optionally
a non-zero initial value.
On 2014/09/19 23:19:12, r wrote:
> zero should be a link

Done.

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1902
doc/go_spec.html:1902: with the expressions following the rules for <a
href="#Assignments">assignments</a>.
On 2014/09/19 23:19:12, r wrote:
> what rules? ordering?
> 
> the old text seems better here. this version doesn't explain the mapping from
> expressions to identifiers

The old rules say that the variables by the expressions in order (we have very
specific evaluation orders for assignments). It says that all expressions must
be consumed and all variables initialized: that's very vague - we have very
specific assignment rules for 1:1, n:n, and n:1 cases. What was here could be
interpreted in a variety of ways.

Happy to include better suggestions.

https://codereview.appspot.com/142320043/diff/40001/doc/go_spec.html#newcode1912
doc/go_spec.html:1912: identifier instead.
On 2014/09/19 23:19:12, r wrote:
> that's an odd way to say it. what does the blank identifier have to do with
it?
> again, the old text seems mostly better

Understood. The reason to bring in the blank identifier is that assignment to
the blank identifier implies the same conversion rules (see Assignments, special
cases at the bottom) and I didn't want to repeat them here. Alternatively, I can
repeat the rule for assignment of untyped values.

Open to suggestions.

[gri, 2014-09-19 23:45:44]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-codereviews@googlegroups.com),

Please take another look.

[r, 2014-09-23 21:07:32]

looks good

https://codereview.appspot.com/142320043/diff/100001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/100001/doc/go_spec.html#newcode...
doc/go_spec.html:1880: non-<a href="#The_zero_value">zero</a> initial value.
you can optionally give it a zero value too.
var a int64 = 0

just drop the "non-zero" part

[gri, 2014-09-23 21:15:06]

PTAL

https://codereview.appspot.com/142320043/diff/100001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/100001/doc/go_spec.html#newcode...
doc/go_spec.html:1880: non-<a href="#The_zero_value">zero</a> initial value.
On 2014/09/23 21:07:32, r wrote:
> you can optionally give it a zero value too.
> var a int64 = 0
> 
> just drop the "non-zero" part

Done.

[iant, 2014-09-24 23:52:33]

LGTM

[rsc, 2014-09-25 19:27:29]

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1879: identifiers to them, and gives each a type and optionally
an initial value.
s/optionally //

The initial value is the zero value if none is given, but that's still an
initial value.
(The type is sometimes implicit too, but that's not marked optional here.)

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:4415: <li><p>
I don't think <p> inside <li> does very much. Most of the <li> in the doc don't
use it.

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:4428: string value.
Everywhere else we use this list we call the thing a constant, not a value.
There are no untyped floating-point values, only untyped floating-point
constants. I know you are trying to allow for untyped bool values but it gets
pretty muddy. Maybe it would help to break this into two cases. Doing so would
let you avoid nil too.

<li>If an untyped constant ... (old text)

<li>If an untyped boolean value is assigned to a variable of interface type or
the blank identifier, it is first converted to type <code>bool</code>.

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:4432: <!-- Note: Consider removing this special case. -->
I believe removing this would create a different special case. It would be the
only place in a program where you can have a nil that has no type. I don't
believe we should do that.

[gri, 2014-09-25 21:52:31]

PTAL

To avoid repetition I introduced the notion of an untyped constant's "default
type" by adding an extra paragraph in the constants section.

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:1879: identifiers to them, and gives each a type and optionally
an initial value.
On 2014/09/25 19:27:29, rsc wrote:
> s/optionally //
> 
> The initial value is the zero value if none is given, but that's still an
> initial value.
> (The type is sometimes implicit too, but that's not marked optional here.)

Done.

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:4415: <li><p>
On 2014/09/25 19:27:29, rsc wrote:
> I don't think <p> inside <li> does very much. Most of the <li> in the doc
don't
> use it.

It does appear to increase the space between <li> items, at least on Chrome. But
fair enough, I removed them for consistency. (I tend to respect white space more
than others ;-)

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:4428: string value.
On 2014/09/25 19:27:29, rsc wrote:
> Everywhere else we use this list we call the thing a constant, not a value.
> There are no untyped floating-point values, only untyped floating-point
> constants. I know you are trying to allow for untyped bool values but it gets
> pretty muddy. Maybe it would help to break this into two cases. Doing so would
> let you avoid nil too.
> 
> <li>If an untyped constant ... (old text)
> 
> <li>If an untyped boolean value is assigned to a variable of interface type or
> the blank identifier, it is first converted to type <code>bool</code>.

Done.

https://codereview.appspot.com/142320043/diff/120001/doc/go_spec.html#newcode...
doc/go_spec.html:4432: <!-- Note: Consider removing this special case. -->
On 2014/09/25 19:27:29, rsc wrote:
> I believe removing this would create a different special case. It would be the
> only place in a program where you can have a nil that has no type. I don't
> believe we should do that.

Acknowledged.

[iant, 2014-09-26 23:55:18]

LGTM

https://codereview.appspot.com/142320043/diff/160001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/160001/doc/go_spec.html#newcode601
doc/go_spec.html:601: An untyped constant has a <i>default type</i> which is the
type the constant
...which is the type to which the constant is implicitly converted in
contexts...

[gri, 2014-09-29 18:00:15]

PTAL

[r, 2014-09-29 22:50:42]

https://codereview.appspot.com/142320043/diff/180001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/180001/doc/go_spec.html#newcode602
doc/go_spec.html:602: constant is implicitly converted in contexts where a typed
value is expected
maybe s/expected/required/

https://codereview.appspot.com/142320043/diff/180001/doc/go_spec.html#newcode603
doc/go_spec.html:603: (for instance, when a constant is <a
href="#Assignments">assigned</a> to an interface).
this is a relatively rare example. i := 0 is much more common and easier to
understand.

for instance, in short variable declaration such as i := 0 where there is no
explicit type

also drop the parens and insert a comma

[gri, 2014-09-29 23:37:27]

PTAL

https://codereview.appspot.com/142320043/diff/180001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/180001/doc/go_spec.html#newcode602
doc/go_spec.html:602: constant is implicitly converted in contexts where a typed
value is expected
On 2014/09/29 22:50:41, r wrote:
> maybe s/expected/required/

Done.

https://codereview.appspot.com/142320043/diff/180001/doc/go_spec.html#newcode603
doc/go_spec.html:603: (for instance, when a constant is <a
href="#Assignments">assigned</a> to an interface).
On 2014/09/29 22:50:41, r wrote:
> this is a relatively rare example. i := 0 is much more common and easier to
> understand.
> 
> for instance, in short variable declaration such as i := 0 where there is no
> explicit type
> 
> also drop the parens and insert a comma

Done.

[r, 2014-09-30 17:46:22]

LGTM

[rsc, 2014-09-30 18:21:08]

LGTM

https://codereview.appspot.com/142320043/diff/200001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/200001/doc/go_spec.html#newcode...
doc/go_spec.html:1930: if it is an untyped boolean value is is first converted
to type <code>bool</code>.
s/value is is/value, it is/

[gri, 2014-09-30 18:44:32]

https://codereview.appspot.com/142320043/diff/200001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/142320043/diff/200001/doc/go_spec.html#newcode...
doc/go_spec.html:1930: if it is an untyped boolean value is is first converted
to type <code>bool</code>.
On 2014/09/30 18:21:07, rsc wrote:
> s/value is is/value, it is/

Done.

[gri, 2014-09-30 18:44:36]

*** Submitted as https://code.google.com/p/go/source/detail?r=4c137c3e4348 ***

spec: clarify variable declaration type rules

Not a language change.

Several inaccuracies were fixed:

1) A variable declaration may declare more than just one
variable.

2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.

3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).

4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.

To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.

Fixes issue 8088.

LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://codereview.appspot.com/142320043