rvalue references

[Andrei Alexandrescu]

On 4/23/13 11:27 AM, Manu wrote:
> On 24 April 2013 00:30, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org <mailto: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.

"scope" is a keyword, not a language feature. In case you are referring 
to scope variables, the feature "scope ref" has little to do with 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?

Many details are missing. This is not a simple problem.

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

That's a possibility, but it's a departure from current semantics and is 
not mentioned in the DIP.

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

Well feeling a certain way is fine but it doesn't help rigorous definitions.

The "scope ref" feature is adding no value over what we have and need to 
get in good order. People would come and ask, "how can a function accept 
both rvalues and lvalues by reference?" and then experts will answer 
with, "well is that a template or a non-template? because the means are 
entirely different". "Why are they different?" And the experts will 
answer just like you: "By definition" - thus closing the circle.

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

This is a new feature. There is no "existing feature scope".

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

It is a feature that has been implemented and works, just not in all cases.

>     In particular we are much more inclined to impart real, demonstrable
>     safety to "ref"
>
>
> ref is unsafe by definition.

We want to aim at making ref safe, thus making it useful as restricted 
pass-down pointers. For full possibilities, one should use pointers.

> I don't believe this is possible without
> some further justification.

The justification is that unsafe uses of ref are few and uninteresting 
(they can be replaced with pointers). It would be very powerful to be 
able to guarantee that safe code can use ref.

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

I don't understand the question as the answer is in it.

> No reference can bind to r-values, r-values can not be addressed.

But auto ref and scope ref do bind to r-values.

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

Our aim is to have ref make that promise.

> ref is fundamentally broken in D right now. DIP36 creates a situation
> where it could be fixed.

A new feature is not a fix.

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

DIP36 should be closed. We must focus on making ref safe and on making 
auto ref work with non-templates.


Andrei