On Wed, Jul 19, 2017 at 3:28 PM, <adrian.pr...@gmail.com> wrote: > > A question on Stack Overflow led me to carefully examine the spec and I feel > like there may be some detail that's missing - the behavior is easy enough to > work with, but it's effectively undefined according to the language spec. > Specifically, with a variable x of type *[]string for example, *x[0] will not > work because it is evaluated as *(x[0]), not as (*x)[0]. This is unexpected > based on the spec because the only specifications that could apply are the > general order of evaluation, which is left to right (not the case here), and > operator precedence which states that pointer dereference is a unary operator > and unary operators have highest precedence (again clearly not what's > happening). > > The closest it comes to explaining this behavior is in the section on address > operators, which implies that the address operator & applies to the entire > slice expression next to it (or struct field selector, etc). This leaves one > to assume the same implication applies to the pointer dereference operator as > well. > > Is there something covering this that I glossed over reading the spec? If > it's not just something I missed, is this worth clarifying in the spec, > without changing the behavior (purely a documentation change)?
This is expressed in the EBNF grammar in the language spec. x[0] is a PrimaryExpr. *x[0] is a unary_op applied to a PrimaryExpr. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
