DIP 36: Rvalue References

[Andrei Alexandrescu]

On 4/23/13 2:29 PM, Manu wrote:
> On 24 April 2013 03:33, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
> wrote:
>     The best setup would be:
>
>     1. To take lvalues by reference, write "ref".
>
>     2. To take lvalues and rvalues by reference, write "auto ref".
>
>
> That's not a good setup at all. It still doesn't make sense.
> There's nothing 'automatic' about it,

There is - it means ref is inferred.

> I've specified ref, it is ref,
> there's no other choice.

Well "auto ref" means "I don't care whether this is ref or not".

> And it relies on a major breaking change to ref, which restricts the
> functionality of ref by default.

This is a confusion. There's no reliance on any change to ref. The 
breaking changes are related to adding safety. If safety weren't a 
concern, a lot of things would be simple.

> Stop talking about r-values, rather, consider safety of passing
> temporaries. This problem has nothing to do with r-values, this is
> equally unsafe:
>    void f(ref int x);
>    int x;
>    f(x);
>
> It's precisely the same problem, and should be fixed with the same solution.

We should make the code above safe as is.

> I would rewrite your list as such:
>
> 1. 'un-safely' pass a value (may not be a local), write 'ref'
> 2. safely pass a value (may be a local), write 'scope ref'
> 3. if you are concerned with templates do you:
> 3.a. want unsafe auto-ref, type 'auto ref' (only non-locals would
> generate 'ref')
> 3.b. want safe auto-ref, type 'scope auto ref'

This a terrible, terrible list. I'd be ashamed to have to explain this 
with a straight face.

>     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.
>
>
> Lifetime of temporaries is the most basic of principles. A local lives
> the life of the function in which it is defined.
> Safety is the whole point, and intrinsic to the proposal; safety by
> explicit specification, thus the programmer retains the option.

The missing point here is inflicting more complexity on the user.


Andrei