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)? -- 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.
