Denis Koroskin wrote:
> On Mon, 14 Dec 2009 22:15:06 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Eldar Insafutdinov wrote:
>>> dsimcha 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);
>>>  My vote for it.
>>
>> Binding rvalues to const references was probably the single most hurtful design decisions for C++. I don't have time to explain now, but in short I think all of the problems that were addressed by rvalue references, and most of the aggravation within the design of rvalue references, are owed by that one particular conversion.
>>
>> If we ever allow automatic conversion of an rvalue to a ref, we should know very well what we're doing.
>>
>>
>> Andrei
> 
> What about allowing binding rvalue to final ref const(T) (final would mean tail-const and wouldn't allow taking address of that variable)?
> 
> Wouldn't that allow the feature while side-stepping all the issues?

It might (though I personally think not), but it would complicate the language. My opinion: if a function wants a ref, give it a ref.

Andrei