May 26, 2015 Re: Evaluation order of index expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | On 05/26/2015 06:13 PM, Artur Skawina via Digitalmars-d wrote:
> On 05/26/15 14:54, Timon Gehr via Digitalmars-d wrote:
>> On 05/26/2015 06:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>>
>>> One of C's design mistakes is to make assignments expressions and not
>>> statements.
>>
>> I think it is more about returning void vs. returning the lvalue. The expression/statement distinction is unnecessary.
>
> int a, b, c;
>
> void f();
> f(a=b);
>
> void g(T...)(T) {}
> g(a=b);
>
> // and, even when 'void' is not a first class type:
> void h(int);
> h(((a=b), c));
>
> artur
>
Sure, but there is no incentive to do this. a[i=j+1]=3; makes the code shorter.
|
May 26, 2015 Re: Evaluation order of index expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 05/26/15 18:16, Timon Gehr via Digitalmars-d wrote: > On 05/26/2015 06:13 PM, Artur Skawina via Digitalmars-d wrote: >> On 05/26/15 14:54, Timon Gehr via Digitalmars-d wrote: >>> On 05/26/2015 06:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote: >>>> >>>> One of C's design mistakes is to make assignments expressions and not statements. >>> >>> I think it is more about returning void vs. returning the lvalue. The expression/statement distinction is unnecessary. >> >> int a, b, c; >> >> void f(); >> f(a=b); >> >> void g(T...)(T) {} >> g(a=b); >> >> // and, even when 'void' is not a first class type: >> void h(int); >> h(((a=b), c)); > Sure, but there is no incentive to do this. a[i=j+1]=3; makes the code shorter. But does it really make sense to allow it?... Simple errors and typos would result in valid but nonsensical code. In a language with proper 'void', type propagation and generics, the compiler wouldn't be able to catch them. Also: auto i() { return a=b; } (a,b) => a=b To get back to the topic; I can only think of two ways: a) "absolute" LTR b) LTR, except assignments and function calls (the latter is necessary for op overloads; fortunately 'this' is already magic in D, and UFCS could be special cased too). artur |
May 26, 2015 Re: Evaluation order of index expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr Attachments: | On Tue, 26 May 2015 18:16:57 +0200, Timon Gehr wrote:
> Sure, but there is no incentive to do this. a[i=j+1]=3; makes the code shorter.
and harder to read. it is considered bad practice anyway, and will hardly pass any serious code review.
|
May 26, 2015 Re: Evaluation order of index expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, 26 May 2015 at 12:51:20 UTC, Timon Gehr wrote:
> I guess overloaded operators could be made to cache the old value. (As they do in CTFE, apparently. :o))
>
> However, this seems like overkill. Any other ideas?
They can but it wouldn't fix anything. The rvalue is already evaluated by then.
|
May 26, 2015 Re: Evaluation order of index expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 05/26/2015 07:48 PM, deadalnix wrote:
> On Tuesday, 26 May 2015 at 12:51:20 UTC, Timon Gehr wrote:
>> I guess overloaded operators could be made to cache the old value. (As
>> they do in CTFE, apparently. :o))
>>
>> However, this seems like overkill. Any other ideas?
>
> They can but it wouldn't fix anything. The rvalue is already evaluated
> by then.
I.e. they can't.
|
May 27, 2015 Re: Evaluation order of index expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, 26 May 2015 at 22:54:55 UTC, Timon Gehr wrote:
> On 05/26/2015 07:48 PM, deadalnix wrote:
>> On Tuesday, 26 May 2015 at 12:51:20 UTC, Timon Gehr wrote:
>>> I guess overloaded operators could be made to cache the old value. (As
>>> they do in CTFE, apparently. :o))
>>>
>>> However, this seems like overkill. Any other ideas?
>>
>> They can but it wouldn't fix anything. The rvalue is already evaluated
>> by then.
>
> I.e. they can't.
You could make the right hand side lazy or something, but yeah, overkill.
|
Copyright © 1999-2021 by the D Language Foundation