That's fine, though my example was for a pointer to a slice of a non-pointer type. Regardless of the type of the slice elements, it evaluates the slice expression first, then the pointer dereference on the result of the expression.
It's not the behavior that concerns me though, it's that it's *undocumented*. The spec should say what happens. The only way to know right now (as far as I can tell) is to try it and figure it out from the compiler errors. I'd think expressed behavior shouldn't be the only documentation for a language aspect. On Wednesday, July 19, 2017 at 6:44:32 PM UTC-4, Jan Mercl wrote: > > > > Consider > > var x *[N]*T > > What is the type of *x[0]? *T or T? Only the parentheses can disambiguate > it: (*x)[0] vs *(x[0]). > > On Thu, Jul 20, 2017, 00:28 <adrian...@gmail.com <javascript:>> 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)? >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > -j > -- > > -j > -- 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.
