On 9/9/10 10:43 CDT, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Thu, 09 Sep 2010 11:24:14 -0400, Eldar Insafutdinov
<e.insafutdi...@gmail.com>  wrote:
I agree that auto ref may be a better option here, but I still see no
reason to
disallow it. It is a performance issue, not a safety one. And as you
said this
only works for templates, virtual functions are out of the game here.

PS. opEquals issue is very annoying, indeed.
Yes, I forgot that you are allowed to overload via ref.  That would make
sense for virtual functions.
The problem with allowing const ref rvalues is then you are not *able* to
make a better performing function, because rvalues match against const ref
as well as the non-ref version.
-Steve

After Bug 4843 (the one I posted this morning about overloading ref vs. non-ref 
w/
structs) is fixed, it might be a good idea to allow auto ref for non-templated
functions as shorthand for a ref function plus a non-ref function that binds to
rvalues and forwards to the ref function.  On the other hand this might be too
much special casing just to save a little typing.  It also might not fly w/ 
Walter
and other people who care about low-level/ABI stuff because it breaks the idea
that, unless something is explicitly a template, one function at source level
should map to one function at the binary level.

There's no need to map auto ref to two functions. It's only about relaxing the checking for rvalue parameters.

The idea will "go" with Walter because it simply is a misunderstanding between design and implementation.


Andrei

Reply via email to