Evaluation order of index expressions
Artur Skawina via Digitalmars-d
digitalmars-d at puremagic.com
Tue May 26 09:49:48 PDT 2015
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 at 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
More information about the Digitalmars-d
mailing list