The liabilities of binding rvalues to ref

Steven Schveighoffer schveiguy at yahoo.com
Thu May 9 10:27:40 PDT 2013


On Thu, 09 May 2013 12:51:04 -0400, Peter Alexander  
<peter.alexander.au at gmail.com> wrote:

> On Thursday, 9 May 2013 at 13:00:44 UTC, Steven Schveighoffer wrote:
>> I have no problem with ref const accepting rvalues.  As I understand  
>> it, Andrei's objection (and this may be wrong/incomplete) is that then  
>> there is no way to say you accept only lvalues as const ref and rvalues  
>> via non-ref (for performance reasons).  But I think there is no  
>> technical reason preventing that with D.
>
> Binding rvalues to ref is also dangerous, because the lifetime of the  
> rvalue is separate from that of the ref, and the ref has no way of  
> knowing when the rvalue will be destroyed.
>
> The ref safety proposal will make it a runtime error to return a  
> reference to a destroyed object, but it would be better if we reduced  
> the opportunities for runtime errors if possible.

I agree, as long as it doesn't make it insanely difficult (i.e. current  
situation) to make types that deal with rvalues.

Short answer: no matter what, we have to find a way to be able to write  
one function that takes by ref, and accepts both rvalues and lvalues.  If  
ref const is that way, so be it.  If auto ref is that way, so be it.  If  
it's plain-old ref, I'm fine with that too.

-Steve


More information about the Digitalmars-d mailing list