April 08, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter wrote: >> You may find an in-depth discussion of the C++ case in >> >> https://stackoverflow.com/questions/7499400/ternary-conditional-and-assignment-operator-precedence > > My formulation was ambiguous, it is the same precedence as the link says. The link also says that's it's right to left evaluation. This means that for expression: > > a ? b = c : d = e; > > > right to left evaluation will make the = e assignment higher priority than the b = c assignment or the ternary even if they have the same priority level. To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value: ccondo1.c --- int main () { int a, b; 1 ? a = 1 : b = 2; return 0; } --- $ cc ccondo1.c ccondo1.c: In function 'main': ccondo1.c:4: error: lvalue required as left operand of assignment Other languages: ---------------- - go: has no ternary conditional - Java: Same as in C, example does not compile due to missing l-value. - JS: Like C++ (!). https://www.ecma-international.org/ecma-262/6.0/#sec-conditional-operator "The grammar for a ConditionalExpression in ECMAScript is slightly different from that in C and Java, which each allow the second subexpression to be an Expression but restrict the third expression to be a ConditionalExpression. The motivation for this difference in ECMAScript is to allow an assignment expression to be governed by either arm of a conditional and to eliminate the confusing and fairly useless case of a comma expression as the centre expression." |
April 08, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to kdevel | On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
> On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter wrote:
>>> You may find an in-depth discussion of the C++ case in
>>>
>>> https://stackoverflow.com/questions/7499400/ternary-conditional-and-assignment-operator-precedence
>>
>> My formulation was ambiguous, it is the same precedence as the link says. The link also says that's it's right to left evaluation. This means that for expression:
>>
>> a ? b = c : d = e;
>>
>>
>> right to left evaluation will make the = e assignment higher priority than the b = c assignment or the ternary even if they have the same priority level.
>
> To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value:
Exactly
Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
|
April 08, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On Sunday, 8 April 2018 at 16:47:59 UTC, Patrick Schluter wrote:
> On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
>> On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter wrote:
>>> [...]
>>
>> To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value:
>
> Exactly
>
>
> Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
To follow up. What's surprizing for a C guy like me is that D accepts without problems
(a=1)=2;
i.e. that (a=1) is a lvalue.
|
April 08, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On Sunday, April 08, 2018 16:59:35 Patrick Schluter via Digitalmars-d wrote:
> On Sunday, 8 April 2018 at 16:47:59 UTC, Patrick Schluter wrote:
> > On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
> >> On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter
> >>
> >> wrote:
> >>> [...]
> >>
> >> To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an
> >
> >> l-value:
> > Exactly
> >
> >
> > Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
>
> To follow up. What's surprizing for a C guy like me is that D accepts without problems
>
> (a=1)=2;
>
> i.e. that (a=1) is a lvalue.
I would fully expect it to be assignable, but I'm a C++ guy, not a C guy. I just tried it with both C, C++, and D though, and it does indeed fail to compile with C while it compiles perfectly fine with C++ and D.
- Jonathan M Davis
|
April 08, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On 04/08/2018 09:59 AM, Patrick Schluter wrote:
> On Sunday, 8 April 2018 at 16:47:59 UTC, Patrick Schluter wrote:
>> On Sunday, 8 April 2018 at 10:03:33 UTC, kdevel wrote:
>>> On Sunday, 8 April 2018 at 07:22:19 UTC, Patrick Schluter wrote:
>>>> [...]
>>>
>>> To summarize: C++ works as expected and C prevents the assigment because the conditional operator does not yield an l-value:
>>
>> Exactly
>>
>>
>> Now, the only thing is to clearly define what it is in D, as apparently it is neither the C++ nor the C behaviour. The old precedence table on the D wiki seems to say it is like C, but the example of that thread seems to show it's not.
>
> To follow up. What's surprizing for a C guy like me is that D accepts without problems
>
> (a=1)=2;
>
> i.e. that (a=1) is a lvalue.
I don't have any problem with that part either. The following makes sense to me. I may have even used it in the past (likely in C++):
(cond ? a : b) = foo;
Ali
|
April 09, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:
> ...
> I don't have any problem with that part either. The following makes sense to me. I may have even used it in the past (likely in C++):
>
> (cond ? a : b) = foo;
> ...
For me as a C programmer this is different. What happens in this case? It will be assign foo to either a or b?
Matt.
|
April 09, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to MattCoder | On Monday, 9 April 2018 at 14:28:54 UTC, MattCoder wrote:
> On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:
>> ...
>> I don't have any problem with that part either. The following makes sense to me. I may have even used it in the past (likely in C++):
>>
>> (cond ? a : b) = foo;
>> ...
>
> For me as a C programmer this is different. What happens in this case? It will be assign foo to either a or b?
>
> Matt.
Depending on the condition, foo will be assigned to either a or b
|
April 09, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to MattCoder | On Monday, 9 April 2018 at 14:28:54 UTC, MattCoder wrote:
> On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:
>> ...
>> I don't have any problem with that part either. The following makes sense to me. I may have even used it in the past (likely in C++):
>>
>> (cond ? a : b) = foo;
>> ...
>
> For me as a C programmer this is different. What happens in this case? It will be assign foo to either a or b?
>
Except that it is not allowed in standard C. gcc says
error: lvalue required as left operand of assignment
to that.
|
April 09, 2018 Re: that is bug? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On Monday, 9 April 2018 at 15:20:58 UTC, Patrick Schluter wrote:
> ...
>> For me as a C programmer this is different. What happens in this case? It will be assign foo to either a or b?
>>
> Except that it is not allowed in standard C. gcc says
> ...
Yes I know, that's why I said, it's different... ("From where I came").
Matt.
|
Copyright © 1999-2021 by the D Language Foundation