The liabilities of binding rvalues to ref

[Andrei Alexandrescu]

On 5/9/13 8:08 PM, Manu wrote:
> On 10 May 2013 09:01, Rob T <alanb at ucora.com <mailto:alanb at ucora.com>>
> wrote:
> It IS confusing that auto-ref would do 2 completely different things.
> One automatically selecting ref-ness, the other saying "i can safely
> receive a temporary". There is nothing 'automatic' about the latter.

The behaviors are strongly related because automatically selecting 
refness entails dealing between rvalues and lvalues.

The most confusing thing would be to choose between:

- ref
- auto ref
- scope ref

It is clear to me things could be designed that way. Practically it 
would be a massive fail because the last two are so closely related, and 
different in ever subtle ways. I could safely say on Walter and my 
behalf that we believe such a design would not serve D well at all.

> As I've had to re-iterate countless times, and such is the massive
> fallacy behind all of these threads, this whole debate is NOT about
> lvalues/rvalues, and I wish people would stop using the term 'rvalue' in
> their posts, I worry that they misunderstand the problem every time it's
> said.

It never hurt any of us to entertain the idea that the fallacy may lie 
within.

> This code is broken:
>    void f(ref int x) {}
>    int x;
>    f(x);

That code is not broken.

> x is an lvalue.
> This is the real problem case, and addressing this will solve the rvalue
> case at the same time.
> Passing an rvalue to a function just generates an implicit temp which is
> functionally identical to the above, except the lifetime of a temp is
> usually the life of the statement rather than the outer scope.
> The problem we need to solve is that of a function being able to safely
> receive a _temporary_.

Oh, you mean an rvalue? :o)


Andrei