rvalue references

[Manu]

On 24 April 2013 00:30, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 4/23/13 10:05 AM, Manu wrote:
>
>> I can't see the fault in DIP36's reasoning. It just makes sense. Why is
>> everyone so against it? I'm yet to understand a reason...
>>
>
> 1. It defines a new language feature instead of improving the existing
> ones. At this point in the development of the language, our preference
> should be putting the existing features in good order.
>

I see it in exactly the opposite way.
This does put an existing feature in good order, ie, scope, which is
defined but barely implemented, and might as well have been invented for
this purpose as far as I can tell from what little information is available
about it.

2. The proposal is sketchy and does not give many details, such as the
> lifetime of temporaries bound to scope ref objects.
>

Is that the only detail missing? An r-value passed this way produces a
temp, which is a stack variable. It's life is identical to any other stack
variable, ie, it lives for the life of the function where it appears.

3. The relationship with auto ref is insufficiently described, e.g. there
> should be clarification on why auto ref cannot be improved to fulfill the
> desired role.
>

auto-ref is a template concept (necessary because ref is not part of the
type like in c++). It doesn't make sense to me at all being forced into
this concept. I see people saying it over and over, but I just can't see it.
How does 'auto' apply conceptually? It's a template concept by definition.
It feels like auto-ref is deliberately contriving a concept to fit a
problem, not DIP36.

4. Above all this is a new language feature and again we want to resort to
> adding new feature only if it is clear that the existing features are
> insufficient and cannot be made sufficient.


Again, I can't see how this is a new feature at all. It's precisely what
you say; making an existing feature (scope) that already exists and is
defined actually work, and elegantly solve the problem.
auto-ref on the other hand IS a new feature (in this context), and it also
makes no sense if you ask me. It's a template concept which is not
applicable here.

In particular we are much more inclined to impart real, demonstrable safety
> to "ref"


ref is unsafe by definition. I don't believe this is possible without some
further justification.
DIP36 however creates a situation where it's known that passing a temp is
actually safe.

and to make "auto ref" work as a reference that can bind to rvalues as well
> as lvalues.


What does it mean to make a reference bind to r-values aswell as l-values?
Lots of people keep saying this too, but it doesn't really make sense to me
either.
No reference can bind to r-values, r-values can not be addressed. It's
really a temp copy of said r-value that we're dealing with, which is an
l-value, ie, a local with a lifetime that's unsuitable for passing by
non-scope-ref.
scope-ref would promise that it won't escape the callee, and thus is safe
to pass a temp.

ref is fundamentally broken in D right now. DIP36 creates a situation where
it could be fixed. I would personally take DIP36 one step further, and ban
all local's from being passed to non-scope ref.
Yes, a breaking change, but you could argue that any code that passes a
stack variable to any ref arg is already broken. But this can be addressed
in a future DIP.


...perhaps I'm missing something fundamental in DIP36, or about 'auto ref'?
I can't understand why there seem to be 2 polarised parties on this issue,
which appear to see the problem completely differently, and can't visualise
the counter perspective at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130424/b74fee9b/attachment-0001.html>