Why do struct literals count as lvalues?

[Timon Gehr]

On 08/19/2011 04:33 PM, kennytm wrote:
> Timon Gehr<timon.gehr at gmx.ch>  wrote:
>> On 08/19/2011 03:46 PM, kennytm wrote:
>>> Timon Gehr<timon.gehr at gmx.ch>   wrote:
>>>
>>>> auto ref currently treats struct literals as lvalues too. (therefore, as
>>>> ref). And passing by value would be considerably less efficient for large structs.
>>>>
>>>> As I understand it, the only issue with allowing literals and function
>>>> results as lvalues is that generic code cannot detect if it is working
>>>> with a temporary or not. I don't know if this would be useful in D though.
>>>>
>>>> each code segment of the form:
>>>>
>>>> void foo(ref S);
>>>> ...
>>>> foo(S(...));
>>>>
>>>> is equivalent to one explicitly declaring the temporary:
>>>>
>>>> {auto __temp=S(...); foo(__temp);}
>>>>
>>>> The difference is that the first is more pleasant to write. If
>>>> temporaries would become rvalues everyone would always have to write the
>>>> second form manually. So imho it is just a syntax sugar issue.
>>>>
>>>> I'd actually argue that ref-passing should work for arbitrary function results too.
>>>
>>> Here I propose that we go a step further and abolish the notion of rvalue
>>> and lvalue entirely, and let the compiler insert necessary temporary
>>> variable when needed, so that we can finally write things like
>>>
>>>       uint w;
>>>       memcpy(w,&5.0f, w.sizeof);
>>>       13u = w;
>>>
>>> </joking>
>>
>> And then of course you could do:
>>
>> 5=6;
>> assert(5==6);
>>
>> It hasn't been working since the good ol' days of fortran =(.
>
> Actually that assignment would just become an expensive no-op because it
> will be rewritten into
>
>      (int __lvalue1243 = 5, __lvalue1243) = 6;
>
> So the assert would still assert.

Nah, no-ops should be a compile error :o).