On Wednesday, 7 November 2012 at 00:47:04 UTC, Jonathan M Davis
wrote:
No, because that would be doing the same thing as C++, which
Walter and Andrei
have already rejected. They specifically do _not_ want there to
be any
ambiguity between whether a const ref variable is an lvalue or
rvalue. If they
were willing to make const ref work the same as C++'s const&,
then we would
never have had this problem in the first place. We specifically
need something
other than const ref. The const ref can continue to work as it
does now, but
we'll have a way to get semantics similar to C++'s const& when
we want them.
Wow, now this finally sheds some light on this topic. Do you have
any links regarding their reasoning?
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).
Especially since the compiler could simply allocate and name the
original rvalue as local variable on the caller's stack before
the function call and hence transform it automatically to an
lvalue, i.e., do that, what currently most of us have to
painfully do by hand.
