temporary objects are not allowed to be pass by ref anymore

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> On Sun, Apr 19, 2009 at 8:41 AM, Denis Koroskin <2korden at gmail.com> wrote:
>> What's a rationale behind an issue described bug 2621?
>> http://d.puremagic.com/issues/show_bug.cgi?id=2621
>>
>> Why isn't it allowed anymore?
>>
>> It broke quite a lot of my code. And while it is fixable by doing
>>
>> auto tmp = someFunctionThatRetunsStruct();
>> someMethodThatAcceptsStructByReference(tmp);
>>
>> it looks ugly and unnecessary.
> 
> I just thought of something.  Why the hell should we keep C++'s "const
> ref" anyway?  When you use "const ref" it means you want it to be
> read-only and fast to pass large structures.  But why should the onus
> of passing value types byref be on the programmer?  Why not make it so
> "const valuetype" will pass byval for smaller values and byref for
> larger, completely freeing the programmer from this tedious crap?
> It's not something that I care about, and the threshold of byval vs.
> byref differs from platform to platform.
> 
> Let's nip this in the bud right now.  A const value type parameter
> should automatically decide whether to pass by reference or not.

I suggested that change. First let me clarify that the suggestion above 
cannot work. Due to aliasing, leaving it to the compiler to choose 
between by-value and by-reference leads to functions breaking when the 
size of the object changes, which is unacceptable.

struct S { int x; ... }
void foo(const S s1, ref S s2)
{
    s1.x = 5;
    s2.x = 6;
}

S s;
foo(s, s); // messed up

Now onto why ref was disallowed to bind to an rvalue. This is because 
some functions take things by ref intending to change them. Passing an 
rvalue is in such cases a bug.

I agree there are functions that only want to use ref for speed 
purposes. I suggested Walter to use ref? for those. ref? means it could 
be an rvalue or an lvalue.


Andrei