Re: [go-nuts] Pointer dereference operator precedence

[adrian . price]

That makes sense, thank you! It does make it a little confusing that a 
special case was made for pointers to arrays that violates that rule, but 
it's a pretty rare use case anyway.

Thanks for pointing this out, it was driving me crazy.

On Thursday, July 20, 2017 at 2:47:12 AM UTC-4, Lyuben Blagoev wrote:
>
> I think the behavior is defined with the following statement in the spec:
>
> Primary expressions are the operands for unary and binary expressions. 
>
> x[0] is a primary expression, so it is the operand for the unary 
> expression, thus the expression is avaluated as *(x[0]).
>
> On Thu, Jul 20, 2017 at 4:07 AM, Ian Lance Taylor  > wrote:
>
>> On Wed, Jul 19, 2017 at 4:10 PM,   
>> wrote:
>> >
>> > The EBNF specifies the syntax, not the behavior. EBNF does not indicate 
>> the
>> > order of evaluation of source code, only the order of characters in the
>> > source code.
>>
>> Fair point.  In this case it is also intended to indicate the
>> precedence.  In fact, in every case I know of, it indicates the
>> precedence.
>>
>> Ian
>>
>> > On Wednesday, July 19, 2017 at 6:59:29 PM UTC-4, Ian Lance Taylor wrote:
>> >>
>> >> On Wed, Jul 19, 2017 at 3:28 PM,   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...@googlegroups.com .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] Pointer dereference operator precedence

[Ian Lance Taylor]

On Wed, Jul 19, 2017 at 4:10 PM,   wrote:
>
> The EBNF specifies the syntax, not the behavior. EBNF does not indicate the
> order of evaluation of source code, only the order of characters in the
> source code.

Fair point.  In this case it is also intended to indicate the
precedence.  In fact, in every case I know of, it indicates the
precedence.

Ian

> On Wednesday, July 19, 2017 at 6:59:29 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Wed, Jul 19, 2017 at 3:28 PM,   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.

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

Re: [go-nuts] Pointer dereference operator precedence

[adrian . price]

The EBNF specifies the syntax, not the behavior. EBNF does not indicate the 
order *of *evaluation of source code, only the order of characters *in *the 
source code.

On Wednesday, July 19, 2017 at 6:59:29 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Jul 19, 2017 at 3:28 PM,   
> 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.