First of all, we should define words for the discussion.

1. Let's name current `auto ref` "parameterized-ref", which works only with template functions and the `auto ref` parameter is instantiated to both ref/non-ref by the actual function argument.

2. Let's call it "rvalue-ref(erence)", which currently discussed, that can receive both lvalues and rvalues by one function body.

2013/4/24 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>

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".

2.2. Is it a non-template? Then write "scope ref".

The difference between 2.1 and 2.2 is not superfluous. Because:

1. "parameterized-ref" is already there with the syntax `auto ref`. Removing it introduces breaking language change.

2. If we remove "parameterized-ref" from D, we will lose the ability to write certain kind of template functions. For example:

auto ref forward(T)(auto ref T arg) { return arg; }

The parameter `arg` is instantiated with both ref/non-ref, and forward `function` returns also both ref/non-ref value. In such case, you cannot replace "parameterized-ref" to "rvalue-ref".

These are why DIP36 is necessary. Repeatedly, I think removing current `auto ref` is not good.

Currently rvalues are destroyed immediately after the call they are passed into. DIP 36 would need to change that, but fails to specify it.

DIP36 does not change it.

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).

I'm basically agreeing with the DIP25. Making `ref` more safety is possible and should.

I can guess that you are intended applying DIP25 to "rvalue-ref" concept. It is sane design, but DIP36 also accepts such applying DIP25. There is no issue.

Andrei

Kenji Hara