code review 6326059: go spec: clean up section on selectors

go spec: clean up section on selectors

- point out difference between selectors and qualified identifiers
- differentiate between illegal selectors and run-time panics
- use "indirect" as opposed to "dereference" consistently
- add extra links

Fixes issue 3779.

[gri, 2012-06-26 18:59:46]

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

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

[iant, 2012-06-26 20:04:04]

FYI

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

http://codereview.appspot.com/6326059/diff/5001/doc/go_spec.html#newcode2392
doc/go_spec.html:2392: <code>nil</code> was assigned to <code>x</code>,
<code>x.f</code>
How about "If x is of pointer or interface type, and has the value nil, x.f
causes a run-time panic."

http://codereview.appspot.com/6326059/diff/5001/doc/go_spec.html#newcode2398
doc/go_spec.html:2398: Selectors automatically <a
href="#Address_operators">indirect</a>
I don't think "indirect" is a transitive verb (though I see that we already use
it as such in the "Method Expressions" section).  I think this sentence was fine
as it was.

[gri, 2012-06-26 20:13:01]

PTAL

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

http://codereview.appspot.com/6326059/diff/5001/doc/go_spec.html#newcode2392
doc/go_spec.html:2392: <code>nil</code> was assigned to <code>x</code>,
<code>x.f</code>
On 2012/06/26 20:04:04, iant wrote:
> How about "If x is of pointer or interface type, and has the value nil, x.f
> causes a run-time panic."

Done.

http://codereview.appspot.com/6326059/diff/5001/doc/go_spec.html#newcode2398
doc/go_spec.html:2398: Selectors automatically <a
href="#Address_operators">indirect</a>
On 2012/06/26 20:04:04, iant wrote:
> I don't think "indirect" is a transitive verb (though I see that we already
use
> it as such in the "Method Expressions" section).  I think this sentence was
fine
> as it was.

Adjusted.

Note: This is the only place where we use "dereference". Should we use it
instead of indirection everywhere?

[iant, 2012-06-26 20:21:43]

LGTM

[rsc, 2012-06-27 14:24:08]

http://codereview.appspot.com/6326059/diff/11001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6326059/diff/11001/doc/go_spec.html#newcode2392
doc/go_spec.html:2392: <code>nil</code>, <code>x.f</code> causes a
s/x.f/assigning to, evaluating, or calling x.f/ ?

Operations, not selectors, cause panics.
Things like &x.f or unsafe.Sizeof(x.f) are fine, for example.

[gri, 2012-06-27 17:54:36]

PTAL

http://codereview.appspot.com/6326059/diff/11001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6326059/diff/11001/doc/go_spec.html#newcode2392
doc/go_spec.html:2392: <code>nil</code>, <code>x.f</code> causes a
On 2012/06/27 14:24:09, rsc wrote:
> s/x.f/assigning to, evaluating, or calling x.f/ ?
> 
> Operations, not selectors, cause panics.
> Things like &x.f or unsafe.Sizeof(x.f) are fine, for example.

good point. fixed.

[r, 2012-06-27 18:14:21]

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html#newcode2333
doc/go_spec.html:2333: For a primary expression <code>x</code> that is not a
should primary expression be a link?

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html#newcode2348
doc/go_spec.html:2348: <a href="#Qualified_identifiers">qualified
identifiers</a>.
does this explain x.y.z? what about if y is a pointer type?

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html#newcode2393
doc/go_spec.html:2393: causes a <a href="#Run_time_panics">run-time panic</a>.
that list feels incomplete. maybe just, any use of x.f causes a panic?

[gri, 2012-06-27 18:34:27]

PTAL

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html#newcode2333
doc/go_spec.html:2333: For a primary expression <code>x</code> that is not a
On 2012/06/27 18:14:21, r wrote:
> should primary expression be a link?

Done.

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html#newcode2348
doc/go_spec.html:2348: <a href="#Qualified_identifiers">qualified
identifiers</a>.
On 2012/06/27 18:14:21, r wrote:
> does this explain x.y.z? what about if y is a pointer type?

x here stands for an arbitrary primary expression, which might be x.y. So I
think this should explain x.y.z (recursively).

http://codereview.appspot.com/6326059/diff/14002/doc/go_spec.html#newcode2393
doc/go_spec.html:2393: causes a <a href="#Run_time_panics">run-time panic</a>.
On 2012/06/27 18:14:21, r wrote:
> that list feels incomplete. maybe just, any use of x.f causes a panic?

As rsc pointed out, e.g. unsafe.Sizeof(x.f) is safe. It seems like this is a
form of "use". If the list is incomplete, we should just complete it.

[r, 2012-06-27 19:31:04]

LGTM but i'm nervous.

[rsc, 2012-06-27 19:31:48]

LGTM

[gri, 2012-06-28 19:22:30]

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

go spec: clean up section on selectors

- point out difference between selectors and qualified identifiers
- differentiate between illegal selectors and run-time panics
- use "indirect" as opposed to "dereference" consistently
- add extra links

Fixes issue 3779.

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