Comment 1:

I suggest that the underlying question is: given a nil pointer p to a struct type.
- Must the expression &p.Field cause a runtime-panic?
- If it is legal, is &p.Field a nil pointer to the type of p.Field?
- What about &*p (which is legal and equal to p currently) ?
My understanding of the current spec is that the answers to these questions are
unspecified.

Comment 2:

- Must the expression &p.Field cause a runtime-panic?
not necessarily, because there are instances in which that might not be a problem, such
as unsafe.Sizeof(&p.Field)
  - If it is legal, is &p.Field a nil pointer to the type of p.Field?
no, because if the field offset is 4, &p.Field is 4 if p is nil.
  - What about &*p (which is legal and equal to p currently) ?
not sure
Perhaps the resolution is to clarify the meaning around indirection of nil pointers.

Labels changed: added priority-soon, removed priority-triage.

Status changed to Accepted.

Comment 4:

- x := &*p
This never fails. The & operator computes the address of an expression. Computing the
address of an expression does not require evaluating it, so *p is never evaluated in
this case. &*p is always just 'p'.
- x := &p.Field
This usually does not fail, for the same reason. However, there is a wrinkle. If you had
var p = (*T)(nil) for
type T struct {
    F0 byte
    F1 byte
    F2 byte
    ...
    F1000000 byte
}
then it is fine to make &p.F2 be pointer value 2, since dereferencing it later will
crash. However, as the field offsets get bigger, eventually you cross into actual memory
values, and you cannot let them through. So right now once you get that far (in the gc
compiler I believe the limit is F4096) x := &p.F4096 will panic rather than return a
pointer you could use without causing a trap. It would be unfortunate to need to talk
about this in the spec.
If we want to avoid the panic, the only other option is to reuse another pointer, like 0
or 1, but that would produce the perhaps odd result that &p.F1 == &p.F4096 or maybe
&p.F0 == &p.F4096 or &p.F4096 == nil. On the other hand it might already be considered
odd that &p.F0 == nil.
The same is true for array types, of course.

Comment 5:

I might be sufficient to explicitly state that the & operators does not require
evaluation of it's operand (in the http://tip.golang.org/ref/spec#Address_operators
section). This solves &*p and &p.Field for "small" field offsets.
The &p.F4096 panic is an implementation issue: For instance, one could conceive an
implementation where pointers are always a pair (base pointer, offset) and the this
panic could be avoided (at the cost of a more expensive implementation). I'd be ok with
a short sentence mentioning an implementation restriction.

Comment 6:

See also good discussion in issue #4464.

Comment 7:

Issue #4464 has been merged into this issue.

Comment 8:

Labels changed: added size-xl.

Comment 9:

Labels changed: added priority-later, removed priority-soon.

Comment 10:

Labels changed: added go1.1maybe, removed go1.1.

Comment 11:

Labels changed: added go1.2maybe, removed go1.1maybe.

Comment 12:

Labels changed: added go1.2, removed go1.2maybe.

Comment 13:

I also want to mention that I expect that if a pointer is not nil, and I did not use
unsafe, then derefrencing it does not panic.
The spec doesn't say it excplicitly at the moment.

Comment 14:

I am not sure the spec should be required to enumerate the things that
don't panic. Addition doesn't panic either, but we don't mention that. It
should suffice to enumerate the list of things that do panic.

Comment 15:

Labels changed: added feature.

Comment 16:

golang.org/s/go12nil. We've decided to do this.
Robert, do you have bandwidth for the spec changes?

Owner changed to @griesemer.

Comment 17:

Probably not today for this one - I suspect it requires some careful combing through the
existing text. Monday.

Comment 18:

Spec change in https://golang.org/cl/12964043

Status changed to Fixed.