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