Rvalue references - The resolution

David Nadlinger see at klickverbot.at
Sat May 4 21:38:20 PDT 2013


On Sunday, 5 May 2013 at 01:45:05 UTC, Jonathan M Davis wrote:
> On Saturday, May 04, 2013 20:37:36 Andrei Alexandrescu wrote:
>> On 5/4/13 7:31 PM, Walter Bright wrote:
>> > On 5/4/2013 3:51 PM, w0rp wrote:
>> >> Does all of this also mean that a
>> >> function with a ref parameter will automagically work with 
>> >> r-values?
>> > 
>> > Yes.
>> 
>> This is new to me. My understanding is that the discussed 
>> design
>> addresses safety, and leaves the rvalue discussion for a 
>> future iteration.
>
> That is definitely where things were when we ended the 
> discussion on Wednesday
> night. Walter favored making ref accept rvalues, but we never 
> agreed on that.
> Manu was still in favor of scop ref (and David Nadlinger agreed 
> with him
> IIRC),

I was mostly arguing against Andrei's (in my opinion) overhasty 
dismissal of anything involving scope ref, because I didn't buy 
his argument about it being a drastic increase in perceived 
language complexity.

I fully agree with runtime-supported escape checking being the 
cleanest design, and like the fact that it is simple.

> and you and I were arguing for auto ref to designate that a 
> function
> accepts rvalues. We all agreed on the bounds check solution for 
> @safety, but
> we explicitly tabled the discussion about accepting rvalues, 
> because it was
> getting late, and we'd already been discussing it / arguing 
> about it for quite
> some time. So, unless further discussion occurred after that 
> which I missed,
> there is still no agreement on how to handle having a parameter 
> accept both
> lvalues and rvalues by ref.

I'd argue that if ref can safely accept rvalues, it should – 
simplicity at its best.

David


More information about the Digitalmars-d mailing list