code review 1536041: go spec: clean-up and consolidation of spec with implem...

go spec: clean-up and consolidation of spec with implementation

Specifically:
- introduced notion of "underlying type"
- removed notion of type compatibility
- consolidated rules about assignment compatibility in
  assignment compatibility section
- be consistent with specyfing that nil is the value
  for uninitialized variables that can be nil (this
  was not specified clearly for pointers, functions, interfaces)
- added/fixed various related links throughout
- clarify language on conversions

[gri, 2010-06-04 01:15:58]

Hello rsc, r, iant, ken2 (cc: golang-dev@googlegroups.com),

I'd like you to review this change.

[r, 2010-06-04 01:25:25]

http://codereview.appspot.com/1536041/diff/5001/6001
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/5001/6001#newcode1236
doc/go_spec.html:1236: if the corresponding type literals are identical; that is
if they have the same
s/; that is /, that is, /

[gri, 2010-06-04 01:30:37]

Hello rsc, r, iant, ken2 (cc: golang-dev@googlegroups.com),

Please take another look.

[rsc1, 2010-06-04 05:32:57]

http://codereview.appspot.com/1536041/diff/20001/21001
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/20001/21001#newcode3256
doc/go_spec.html:3256: If the value is a signed quantity, it is
This section is missing a clear statement of what's legal.
There are various sentences that imply certain things must be
legal, but there is less room for debate if the spec just says it. 
Maybe merge the two sections, which already have some overlap,
and then start with a simple statement of what's allowed followed
by the list of details of individual cases:

<h4>Conversions between numeric types</h4>

A value of an integer or floating point type can be converted to any integer or
floating point type.
A value of a complex type can be converted to any complex type.

<ol>
<li>If a signed integer value is converted to an integer type, it is sign
extended ...
<li>When converting a floating-point number ...
<li>In all conversions involving floating-point or ...
<li>A conversion to floating point or complex type always rounds to the
precision ...
<li>There are no conversions from integer or floating point type to complex
type, nor vice versa.
    Use real, imag, and cmplx instead.
</ol>

[rsc1, 2010-06-04 06:39:27]

http://codereview.appspot.com/1536041/diff/20001/21001
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/20001/21001#newcode3240
doc/go_spec.html:3240: <code>x</code> is of an unnamed pointer type and type
<code>T</code> is another
I tried implementing this.  It doesn't work.
    *bufio.Reader is assignment compatible to io.Reader
so by this rule 
    **bufio.Reader is assignment compatible to *io.Reader
which is not good (struct pointer vs interface pointer).

Maybe it would work to say

1. The value of x is assignment compatible to T.
2. The type of x and the type T would be identical if they were unnamed.
3. The type of x and the type T are unnamed pointer types and the previous
    condition applies to the pointer base types.

But now unnamed feels wrong (what does it mean to say
"if type string were unnamed"?).  I think we agree about
what we're trying to say, but we're not saying it well.
I'm going to keep trying to clean up the type operations in
the compiler and see if I end up with something clean
that can be translated back into English.

[rsc, 2010-06-04 07:46:15]

I think something like this can be made to mean what we want.
(It is derived from what's in the spec now but addresses the
problem I pointed out in my last mail.)

***

The <i>underlying type</i> of a type T is the predefined type
or type literal used, perhaps indirectly, in T's definition.

    type T1 string
    type T2 T1
    type T3 []T1
    type T4 T3

The underlying type of string, T1, and T2 is string.
The underlying type of []T1, T3, and T4 is []T1.

***

A value x can be assigned to type T in any of these cases:

   1. x's type is identical to T.
   2. x's type V and T have identical underlying types
      and either V or T is not a named type.
   3. T is an interface type and x implements T.
   4. x is a bidirectional channel value,
      T is a channel type,
      x's type V and T have identical element types,
      and either V or T is not a named type.
   5. x is the predeclared identifier nil
      and T is a pointer, func, slice, map, channel, or interface type.
   6. x is an untyped constant representable by a value of type T.

If T is a struct type, the assignment is valid only if ... (lowercase rule).

Special case for assignment statements:
any typed value or untyped constant can be assigned to
the blank identifier.

(I avoided writing x of type V at the top because x might not have a type:
it might be nil or 3.14.)

***

A value x can be converted to type T in any of these cases:

   1. x can be assigned to type T.
   2. x's type and T have identical underlying types.
   3. x's type and T are unnamed pointer types and their
      and their pointer base types have identical underlying types.
   4. x's type and T are both integer or floating point types.
   5. x's type and T are both complex types.
   6. x is an integer or has type []byte or []int
      and T is a string type.
   7. x is a string and T is []byte or []int.

(and then elaborate the meaning of the last few;
I avoided writing x's type in 6 and 7 because x may be
an untyped constant.)

***

I was surprised that "can be assigned to" works in place of
assignment compatible; in fact I find its meaning easier to
remember, because the direction of the assignment is clear.

[gri, 2010-06-04 18:43:31]

I still find this more complicated then I'd like it to be. Specifically, I
still wish we could just say that types must be identical to be assignment
compatible (with the exceptions for interfaces, nil, untyped constants), and
that for conversions (excluding the conversions that actually change
representation) we could just convert anything that has the same memory
layout. As it is now, such type conversions are only marginally more
powerful than assignment compatibility (they strip the top level of naming).

We would have to introduce some conversions (as we have seen, almost all of
them are reasonable), but it would be much simpler to understand.

As for the notion "underlying type": If we would instead define the
"fundamental type" as the type literal after stripping all user-introduced
names (i.e., the fundamental type is the type literal with all user-named
types "inlined" and thus represents the memory layout) and if we would say
that (type) conversion is permitted when the fundamental types are
identical, conversion would be more powerful and easier to understand. As it
is now (as a result of making making compatibility "flat"), conversions have
lost a lot of power (I'm taking some blame for that).

- Robert

On Fri, Jun 4, 2010 at 12:46 AM, Russ Cox <rsc@golang.org> wrote:

> I think something like this can be made to mean what we want.
> (It is derived from what's in the spec now but addresses the
> problem I pointed out in my last mail.)
>
> ***
>
> The <i>underlying type</i> of a type T is the predefined type
> or type literal used, perhaps indirectly, in T's definition.
>
>    type T1 string
>    type T2 T1
>    type T3 []T1
>    type T4 T3
>
> The underlying type of string, T1, and T2 is string.
> The underlying type of []T1, T3, and T4 is []T1.
>
> ***
>
> A value x can be assigned to type T in any of these cases:
>
>   1. x's type is identical to T.
>   2. x's type V and T have identical underlying types
>      and either V or T is not a named type.
>   3. T is an interface type and x implements T.
>   4. x is a bidirectional channel value,
>      T is a channel type,
>      x's type V and T have identical element types,
>      and either V or T is not a named type.
>   5. x is the predeclared identifier nil
>      and T is a pointer, func, slice, map, channel, or interface type.
>   6. x is an untyped constant representable by a value of type T.
>
> If T is a struct type, the assignment is valid only if ... (lowercase
> rule).
>
> Special case for assignment statements:
> any typed value or untyped constant can be assigned to
> the blank identifier.
>
> (I avoided writing x of type V at the top because x might not have a type:
> it might be nil or 3.14.)
>
> ***
>
> A value x can be converted to type T in any of these cases:
>
>   1. x can be assigned to type T.
>   2. x's type and T have identical underlying types.
>   3. x's type and T are unnamed pointer types and their
>      and their pointer base types have identical underlying types.
>   4. x's type and T are both integer or floating point types.
>   5. x's type and T are both complex types.
>   6. x is an integer or has type []byte or []int
>      and T is a string type.
>   7. x is a string and T is []byte or []int.
>
> (and then elaborate the meaning of the last few;
> I avoided writing x's type in 6 and 7 because x may be
> an untyped constant.)
>
> ***
>
> I was surprised that "can be assigned to" works in place of
> assignment compatible; in fact I find its meaning easier to
> remember, because the direction of the assignment is clear.
>

[rsc, 2010-06-04 18:54:04]

On Fri, Jun 4, 2010 at 11:43, Robert Griesemer <gri@golang.org> wrote:
> I still find this more complicated then I'd like it to be....

I agree - it's complicated - but I also believe it is an accurate
reflection of what the current rules are.  We could discuss the
merits of the current rules separately, but I think it makes sense
to put that off until we've precisely defined the status quo.

Russ

[gri, 2010-06-04 19:00:49]

On Fri, Jun 4, 2010 at 11:53 AM, Russ Cox <rsc@golang.org> wrote:

> On Fri, Jun 4, 2010 at 11:43, Robert Griesemer <gri@golang.org> wrote:
> > I still find this more complicated then I'd like it to be....
>
> I agree - it's complicated - but I also believe it is an accurate
> reflection of what the current rules are.  We could discuss the
> merits of the current rules separately, but I think it makes sense
> to put that off until we've precisely defined the status quo.
>

Agreed. I'm about to rework the CL.
- Robert

>
> Russ
>

[gri, 2010-06-04 20:38:09]

Hello rsc, r, iant, ken2 (cc: golang-dev@googlegroups.com),

Please take another look.

[r, 2010-06-04 21:53:44]

http://codereview.appspot.com/1536041/diff/33002/2002
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/33002/2002#newcode615
doc/go_spec.html:615: <a href="#Declarations_and_scope">declaration</a>.
this is not a clear definition. "perhaps indirectly" is too vague.  and "type
literal" doesn't work for me since all it means is the right-hand side of a
declaration.

i think the word we want for named type is declared type.

type T int

declares T an int, so T is a declared type.  That is, a declared type is a type
given a name in a type declaration in the program (or its imports).

then we can say that all types that are not declared types are undeclared types.
examples include int, *string, map[int]string, <-chan T, etc.  this seems like a
very clear definition.

The underlying type of T is the undeclared type to which it refers by
declaration.  If the type literal in T's declaration is an undeclared type, the
underlying type of T is the type of the literal; otherwise by definition the
declaration of T uses a declared type T1 (or pkg.T2) as its type literal, and
the underlying type of T is the underlying type of T1 (or of pkg.T2).

[gri, 2010-06-04 22:32:15]

On Fri, Jun 4, 2010 at 2:53 PM, <r@golang.org> wrote:

>
> http://codereview.appspot.com/1536041/diff/33002/2002
> File doc/go_spec.html (right):
>
> http://codereview.appspot.com/1536041/diff/33002/2002#newcode615
> doc/go_spec.html:615: <a href="#Declarations_and_scope">declaration</a>.
> this is not a clear definition. "perhaps indirectly" is too vague.  and
> "type literal" doesn't work for me since all it means is the right-hand
> side of a declaration.
>

Actually, type literal refers to the syntax rule TypeLit (which is not and
does not include TypeName). I do agree that the "definition" is vague and
should be improved.


> i think the word we want for named type is declared type.
>
> type T int
>
> declares T an int, so T is a declared type.  That is, a declared type is
> a type given a name in a type declaration in the program (or its
> imports).
>

then we can say that all types that are not declared types are
> undeclared types. examples include int, *string, map[int]string, <-chan
> T, etc.  this seems like a very clear definition.
>

If int is not a declared type, "declared type" has a different meaning than
"named type". Right now, it is not legal to assign a MyInt to an int,
because both of them are named, and they are named differently. This is a
property we definitively want to have. With your definition, int is
undeclared, MyInt is declared, and they become assignment compatible.

I don't mind the notion of "declared type" but I think it must include
predeclared types. But then I am not sure it's much better than named type.
Type literal explicitly eliminates type names, which is the reason why I was
using this term in the first place.

- gri



> The underlying type of T is the undeclared type to which it refers by
> declaration.  If the type literal in T's declaration is an undeclared
> type, the underlying type of T is the type of the literal; otherwise by
> definition the declaration of T uses a declared type T1 (or pkg.T2) as
> its type literal, and the underlying type of T is the underlying type of
> T1 (or of pkg.T2).
>
>
> http://codereview.appspot.com/1536041/show
>

[r2, 2010-06-04 22:42:40]

Understood, but for the purposes of this explanation "undeclared type" is easier
to internalize.

[rsc1, 2010-06-05 00:22:58]

http://codereview.appspot.com/1536041/diff/33002/2002
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/33002/2002#newcode615
doc/go_spec.html:615: <a href="#Declarations_and_scope">declaration</a>.
> i think the word we want for named type is declared type.

I'm not comfortable calling int undeclared here but referring
to it as a "predeclared identifier" elsewhere in the spec.

[gri, 2010-06-05 00:30:52]

On Fri, Jun 4, 2010 at 5:22 PM, <rsc@google.com> wrote:

>
> http://codereview.appspot.com/1536041/diff/33002/2002
> File doc/go_spec.html (right):
>
> http://codereview.appspot.com/1536041/diff/33002/2002#newcode615
> doc/go_spec.html:615: <a href="#Declarations_and_scope">declaration</a>.
>
>> i think the word we want for named type is declared type.
>>
>
> I'm not comfortable calling int undeclared here but referring
> to it as a "predeclared identifier" elsewhere in the spec.


I am fine to move everything to declared vs. undeclared type, where
"declared type" means the same as what "named type" means now. Specifically,
predeclared types are "declared". However, this is different from Rob's
suggestion.

- Robert


>
>
> http://codereview.appspot.com/1536041/show
>

[gri, 2010-06-05 00:31:26]

On Fri, Jun 4, 2010 at 5:22 PM, <rsc@google.com> wrote:

>
> http://codereview.appspot.com/1536041/diff/33002/2002
> File doc/go_spec.html (right):
>
> http://codereview.appspot.com/1536041/diff/33002/2002#newcode615
> doc/go_spec.html:615: <a href="#Declarations_and_scope">declaration</a>.
>
>> i think the word we want for named type is declared type.
>>
>
> I'm not comfortable calling int undeclared here but referring
> to it as a "predeclared identifier" elsewhere in the spec.


I am fine to move everything to declared vs. undeclared type, where
"declared type" means the same as what "named type" means now. Specifically,
predeclared types are "declared". However, this is different from Rob's
suggestion.

- Robert


>
>
> http://codereview.appspot.com/1536041/show
>

[r2, 2010-06-05 00:33:43]

On Jun 4, 2010, at 5:28 PM, Robert Griesemer wrote:

> On Fri, Jun 4, 2010 at 5:22 PM, <rsc@google.com> wrote:
> 
> http://codereview.appspot.com/1536041/diff/33002/2002
> File doc/go_spec.html (right):
> 
> http://codereview.appspot.com/1536041/diff/33002/2002#newcode615
> doc/go_spec.html:615: <a href="#Declarations_and_scope">declaration</a>.
> i think the word we want for named type is declared type.
> 
> I'm not comfortable calling int undeclared here but referring
> to it as a "predeclared identifier" elsewhere in the spec.
> 
> I am fine to move everything to declared vs. undeclared type, where "declared
type" means the same as what "named type" means now. Specifically, predeclared
types are "declared". However, this is different from Rob's suggestion.

I'm happy with it too. 

-rob

[rsc, 2010-06-05 00:42:01]

>>>
>>> i think the word we want for named type is declared type.
>>
>> I'm not comfortable calling int undeclared here but referring
>> to it as a "predeclared identifier" elsewhere in the spec.
>
> I am fine to move everything to declared vs. undeclared type, where
> "declared type" means the same as what "named type" means now. Specifically,
> predeclared types are "declared". However, this is different from Rob's
> suggestion.

I may not understand, but this sounds like a language change.
Examples of an "underlying type" as used in the CL include *string or int.

Defining a "declared type" to be the same thing as what we
now call a "named type" does not sound like it would help
replace "underlying type", because int is named while *string is not.

Russ

[gri, 2010-06-05 00:48:30]

On Fri, Jun 4, 2010 at 5:41 PM, Russ Cox <rsc@golang.org> wrote:

> >>>
> >>> i think the word we want for named type is declared type.
> >>
> >> I'm not comfortable calling int undeclared here but referring
> >> to it as a "predeclared identifier" elsewhere in the spec.
> >
> > I am fine to move everything to declared vs. undeclared type, where
> > "declared type" means the same as what "named type" means now.
> Specifically,
> > predeclared types are "declared". However, this is different from Rob's
> > suggestion.
>
> I may not understand, but this sounds like a language change.
> Examples of an "underlying type" as used in the CL include *string or int.
>
> Defining a "declared type" to be the same thing as what we
> now call a "named type" does not sound like it would help
> replace "underlying type", because int is named while *string is not.
>

Agreed - which is why I pointed out that "declared type" == "named type" is
different from what "declared type" meant in Rob's first suggestion.

I am only saying that if the consensus is that "declared type" is a better
notion than "named type" then I am happy to try to make that change.
Specifically, all predeclared types would be declared types.

But since this is not directly helping the definition of  "underlying type",
this can be done in a separate CL if we feel it's clearly better then using
"named type" (I am not convinced, but I am not against it, either).

Pending the better definition for "underlying type" - which I believe we
understand what it means - are there any other issues with the current spec
changes?

- Robert



> Russ
>

[gri, 2010-06-05 00:49:02]

On Fri, Jun 4, 2010 at 5:41 PM, Russ Cox <rsc@golang.org> wrote:

> >>>
> >>> i think the word we want for named type is declared type.
> >>
> >> I'm not comfortable calling int undeclared here but referring
> >> to it as a "predeclared identifier" elsewhere in the spec.
> >
> > I am fine to move everything to declared vs. undeclared type, where
> > "declared type" means the same as what "named type" means now.
> Specifically,
> > predeclared types are "declared". However, this is different from Rob's
> > suggestion.
>
> I may not understand, but this sounds like a language change.
> Examples of an "underlying type" as used in the CL include *string or int.
>
> Defining a "declared type" to be the same thing as what we
> now call a "named type" does not sound like it would help
> replace "underlying type", because int is named while *string is not.
>

Agreed - which is why I pointed out that "declared type" == "named type" is
different from what "declared type" meant in Rob's first suggestion.

I am only saying that if the consensus is that "declared type" is a better
notion than "named type" then I am happy to try to make that change.
Specifically, all predeclared types would be declared types.

But since this is not directly helping the definition of  "underlying type",
this can be done in a separate CL if we feel it's clearly better then using
"named type" (I am not convinced, but I am not against it, either).

Pending the better definition for "underlying type" - which I believe we
understand what it means - are there any other issues with the current spec
changes?

- Robert



> Russ
>

[r2, 2010-06-05 02:19:16]

On Jun 4, 2010, at 5:47 PM, Robert Griesemer wrote:

> Agreed - which is why I pointed out that "declared type" == "named type" is
different from what "declared type" meant in Rob's first suggestion.

On further reflection I am backing up to my previous position, in which int is
an undeclared type, since that is the simplest path I can see to have the
definition of underlying type make sense.

-rob

[gri, 2010-06-07 21:51:40]

Please have another look:

http://codereview.appspot.com/1536041

- clean definition of "underlying type"
- Various minor fixes

- gri

[rsc1, 2010-06-07 21:58:41]

lgtm

http://codereview.appspot.com/1536041/diff/20002/45001
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/20002/45001#newcode616
doc/go_spec.html:616: is the underlying type of the type to which <code>T</code>
refers to in its
s/to which/which/ or s/refers to/refers/

http://codereview.appspot.com/1536041/diff/20002/45001#newcode3307
doc/go_spec.html:3307: <h4>Conversions involving floating point and complex
types</h4>
drop h4; merge into previous section?

[r, 2010-06-07 22:04:05]

it's getting close

http://codereview.appspot.com/1536041/diff/20002/45001
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/20002/45001#newcode616
doc/go_spec.html:616: is the underlying type of the type to which <code>T</code>
refers to in its
the second 'to' is superfluous

http://codereview.appspot.com/1536041/diff/20002/45001#newcode617
doc/go_spec.html:617: <a href="#Type_declarations">type declaration</a>.
good definition

http://codereview.appspot.com/1536041/diff/20002/45001#newcode651
doc/go_spec.html:651: <a href="#Assignment_compatibility">assignment
compatible</a>
not for this round, but i think we can get rid of the word "assignment" in
"assignment compatible".  things are just compatible now, aren't they?

http://codereview.appspot.com/1536041/diff/20002/45001#newcode1339
doc/go_spec.html:1339: is not a named type.
picky grammar: one of V or T, or both?

[gri, 2010-06-07 22:28:02]

On Mon, Jun 7, 2010 at 2:58 PM, <rsc@google.com> wrote:

> lgtm
>
>
>
> http://codereview.appspot.com/1536041/diff/20002/45001
>
> File doc/go_spec.html (right):
>
> http://codereview.appspot.com/1536041/diff/20002/45001#newcode616
> doc/go_spec.html:616: is the underlying type of the type to which
> <code>T</code> refers to in its
> s/to which/which/ or s/refers to/refers/
>
done

>
> http://codereview.appspot.com/1536041/diff/20002/45001#newcode3307
> doc/go_spec.html:3307: <h4>Conversions involving floating point and
> complex types</h4>
> drop h4; merge into previous section?
>
> http://codereview.appspot.com/1536041/show

done

[gri, 2010-06-07 22:29:58]

PTAL.
- gri

On Mon, Jun 7, 2010 at 3:04 PM, <r@golang.org> wrote:

> it's getting close
>
>
>
> http://codereview.appspot.com/1536041/diff/20002/45001
> File doc/go_spec.html (right):
>
> http://codereview.appspot.com/1536041/diff/20002/45001#newcode616
> doc/go_spec.html:616: is the underlying type of the type to which
> <code>T</code> refers to in its
> the second 'to' is superfluous
>
done

>
> http://codereview.appspot.com/1536041/diff/20002/45001#newcode617
> doc/go_spec.html:617: <a href="#Type_declarations">type declaration</a>.
> good definition
>
> http://codereview.appspot.com/1536041/diff/20002/45001#newcode651
> doc/go_spec.html:651: <a href="#Assignment_compatibility">assignment
> compatible</a>
> not for this round, but i think we can get rid of the word "assignment"
> in "assignment compatible".  things are just compatible now, aren't
> they?
>
yes - another CL

>
> http://codereview.appspot.com/1536041/diff/20002/45001#newcode1339
> doc/go_spec.html:1339: is not a named type.
> picky grammar: one of V or T, or both?

both is fine, too. it doesn't matter which is why I left out that "one of"

>
>
> http://codereview.appspot.com/1536041/show
>

[r, 2010-06-07 22:35:01]

http://codereview.appspot.com/1536041/diff/48001/49001
File doc/go_spec.html (right):

http://codereview.appspot.com/1536041/diff/48001/49001#newcode616
doc/go_spec.html:616: is the underlying type of the type which <code>T</code>
refers to in its
the second 'to' was the wrong one.
the type to which T refers in its

[r, 2010-06-07 22:43:57]

LGTM

[iant, 2010-06-07 22:48:50]

LGTM

[gri, 2010-06-07 22:49:49]

*** Submitted as http://code.google.com/p/go/source/detail?r=fd33a7545685 ***

go spec: clean-up and consolidation of spec with implementation

Specifically:
- introduced notion of "underlying type"
- removed notion of type compatibility
- consolidated rules about assignment compatibility in
  assignment compatibility section
- be consistent with specyfing that nil is the value
  for uninitialized variables that can be nil (this
  was not specified clearly for pointers, functions, interfaces)
- added/fixed various related links throughout
- clarify language on conversions

R=rsc, r, iant, ken2
CC=golang-dev
http://codereview.appspot.com/1536041