const ref rvalues

[Andrei Alexandrescu]

Denis Koroskin wrote:
> On Mon, 14 Dec 2009 23:38:34 +0300, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Denis Koroskin wrote:
>>> On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha <dsimcha at yahoo.com> wrote:
>>>
>>>> I mentioned this deep in another thread, but I think it deserves its 
>>>> own
>>>> thread.  Can we get something like:
>>>>
>>>> void doStuff(T)(const ref T val) {
>>>>     // do stuff.
>>>> }
>>>>
>>>> T getVal() {
>>>>     return someValue;
>>>> }
>>>>
>>>> void main() {
>>>>     doStuff(getVal());  // Doesn't currently work.
>>>> }
>>>>
>>>> For non-const ref parameters, it's understandable that passing 
>>>> rvalues in
>>>> doesn't work because this is likely a bug that the compiler should 
>>>> catch.
>>>> However, for const ref parameters, can't the compiler just 
>>>> implicitly put the
>>>> value on the caller's stack frame and convert it to an lvalue rather 
>>>> than
>>>> forcing the programmer to write the boilerplate to do this 
>>>> manually?  This
>>>> would result in:
>>>>
>>>> doStuff(getVal()); -->
>>>>
>>>> auto __temp = getVal();
>>>> doStuff(__temp);
>>>  I agree it hurts a lot. I faced the same problem implementing 
>>> RefCounted: you can't return RefCounted object from one function and 
>>> pass it by reference to another one. Passing it by value is not a 
>>> good option.
>>
>> The compiler will optimize that case.
>>
>> Andrei
> 
> How can it optimize away a function with a side effect (RefCounted 
> ctor/dtor invokes an interlocked increment/decrement that theoretically 
> may destroy an object, but wouldn't in practice)? Make it special for 
> compiler?

The compiler can optimize away all copies followed by the destruction of 
the source. It suffices to just move memory.

Andrei