Const ref and rvalues again...

[martin]

On Wednesday, 7 November 2012 at 01:15:27 UTC, martin wrote:
> I simply and utterly fail to comprehend the need for a compiler 
> to distinguish between a const reference to a named variable 
> and a const reference to an unnamed temporary/literal (which 
> the compiler is free to allocate wherever it makes most sense).

Let me be more precise: I don't see why a called function would 
need to know whether a passed const reference is named or unnamed 
at the caller's site. The developer's reasoning for a const 
reference is simply to avoid costly copying of the argument to be 
passed (only applicable for lvalues) which is guaranteed not to 
be modified by the callee. Decorating such a parameter with 
'const ref' seems as logical as it gets (don't pass me a copy of 
the real thing, pass me a reference instead - I'm not going to 
modify it).
The only reason I can think of to distinguish between lvalues and 
rvalues at the callee is the slight performance hit due to 
pointer indirection for rvalues. And that would be addressable by 
preferring by-value-passing of rvalues when selecting between 
function overloads.