code review 168790043: spec: method selectors don't auto-deref named pointer types

spec: method selectors don't auto-deref named pointer types

Language clarification.

The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).

However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.

Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).

Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.

Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:

See http://play.golang.org/p/c6VhjcIVdM , line 45.

Fixes issue 5769.
Fixes issue 8989.

[gri, 2014-10-29 18:54:31]

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-11-01 14:14:50]

LGTM

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

https://codereview.appspot.com/168790043/diff/40001/doc/go_spec.html#newcode2524
doc/go_spec.html:2524: where <code>T</code> is not pointer or interface type,
s/pointer/a &/

[gri, 2014-11-03 05:19:01]

PTAL

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

https://codereview.appspot.com/168790043/diff/40001/doc/go_spec.html#newcode2524
doc/go_spec.html:2524: where <code>T</code> is not pointer or interface type,
On 2014/11/01 14:14:50, r wrote:
> s/pointer/a &/

Done.

[rsc, 2014-11-07 00:32:32]

LGTM

https://codereview.appspot.com/168790043/diff/60001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/168790043/diff/60001/doc/go_spec.html#newcode2561
doc/go_spec.html:2561: As an exception, if the type of <code>x</code> is a named
pointer type
If you move this up above (to line 2540) then the edit on line 2542 can go away
and it goes back to "In all other cases ...".
As written it's a bit weird to go into run-time panics and then come back to
which selectors are valid.

[gri, 2014-11-07 23:21:53]

https://codereview.appspot.com/168790043/diff/60001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/168790043/diff/60001/doc/go_spec.html#newcode2561
doc/go_spec.html:2561: As an exception, if the type of <code>x</code> is a named
pointer type
On 2014/11/07 00:32:32, rsc wrote:
> If you move this up above (to line 2540) then the edit on line 2542 can go
away
> and it goes back to "In all other cases ...".
> As written it's a bit weird to go into run-time panics and then come back to
> which selectors are valid.

Done.

[gri, 2014-11-11 21:19:54]

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

spec: method selectors don't auto-deref named pointer types

Language clarification.

The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).

However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.

Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).

Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.

Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:

See http://play.golang.org/p/c6VhjcIVdM , line 45.

Fixes issue 5769.
Fixes issue 8989.

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