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.

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

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.

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.

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.

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.