R-values and const ref

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Sep 9 10:09:03 PDT 2010


On 9/9/10 10:43 CDT, dsimcha wrote:
> == Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
>> On Thu, 09 Sep 2010 11:24:14 -0400, Eldar Insafutdinov
>> <e.insafutdinov at 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


More information about the Digitalmars-d mailing list