DIP 36: Rvalue References

[Timon Gehr]

On 04/23/2013 07:33 PM, Andrei Alexandrescu wrote:
> On 4/23/13 12:04 PM, Manu wrote:
>> On 24 April 2013 00:24, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
>> wrote:
>>
>>
>>         The very point of this DIP is to not create
>>         syntax-driven features, instead better define existing ones that
>>         make
>>         sense on their own so they can be used for same purpose.
>>
>>
>>     It's a new feature, no two ways about it. It overlaps ref and auto
>>     ref without any palpable benefit and defines yet another way to
>>     achieve the same thing as auto ref. On this ground alone the
>>     proposal has a large problem.
>>
>>
>> How does it overlap ref? It simply justifies the argument with an extra
>> constraint and isn't tied to 'ref' at all, it's just useful in
>> conjunction.
>
> The best setup would be:
>
> 1. To take lvalues by reference, write "ref".
>
> 2. To take lvalues and rvalues by reference, write "auto ref".
>
> Everything else is superfluous and puts the burden of justification on
> the proposer. With DIP36, the setup would be:
>
> 1. To take lvalues by reference, write "ref".
>
> 2. To take lvalues and rvalues by reference:
>
> 2.1. Is it a template? Then write "auto ref".
>

or "scope ref", to be fair. scope ref on a template would behave 
differently than auto ref on a template.

> 2.2. Is it a non-template? Then write "scope ref".
>
>> I can't agree that it overlaps auto-ref at all. They're fundamentally
>> different concepts. auto-ref is a template concept; it selects the
>> ref-ness based on the received arg. 'auto ref', ie, 'automatic
>> ref-ness'. It makes no sense on a non-template situation.
>> I'm still completely amazed that the very reason this DIP makes perfect
>> sense to me(/us) is the same reason you have a problem with it.
>
> I don't know how to respond to this. To me is it painfully obvious DIP
> 36 is poor language design and fails to solve a variety of issues, such
> as clarifying lifetime of temporaries, safety, and returning ref from
> functions.
>

+1.

> ...
>
> Our intent is to make "ref" always scoped and reserve non-scoped uses to
> pointers. We consider this good language design: we have unrestricted
> pointers for code that doesn't care much about safety, and we have "ref"
> which is almost as powerful but sacrifices a teeny bit of that power for
> the sake of guaranteed safety. Safety is guaranteed by making sure "ref"
> is always scoped (references can be passed down but never escape their
> bound value).
> ...

Safety should be guaranteed in @safe code. There is no point in 
conservatively disallowing perfectly fine @system code on the basis of 
safety concerns, unless, of course, the type system is advanced enough 
to prove safe all relevant use cases.