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