The liabilities of binding rvalues to ref

[Manu]

On 10 May 2013 09:01, Rob T <alanb at ucora.com> wrote:

> On Thursday, 9 May 2013 at 21:55:51 UTC, Manu wrote:
>
>> Umm, what if the non-template counterpart returns ref? Then it doesn't
>> behave the same.
>>
>
> Yes, the non-template version cannot ref return an auto ref param, but I
> would expect that neither can the template version unless auto ref is
> specified as the return value. The key difference that I think can be
> understood is that auto ref on the return value for a template is not the
> same thing as auto ref on the param.
>
> For templates, you can enforce exactly the same behavior as the
> non-template version by specifying a return of either ref or not, ie you do
> not specify auto ref or you specify a return by value.
>
> If you so happen to specify a ref return of an auto ref param, I would
> expect the compiler to refuse to compile no matter if it is a template
> function or not. Of course you can confuse the programmer and allow such a
> thing to compile only for the cases where it can return ref on the auto
> ref, but IMO that'll be a big mistake as it will confuse the s*** out of
> most people, and besides allowing something like that has no value at all.
>
>  D is a complex language, so stuff like this does take some getting used
>> to,
>>
>>> but it is very powerful and flexible, no two ways around it.
>>>
>>>
>> If this takes 'getting used to', you're basically admitting that it
>> doesn't
>> make intuitive sense.
>>
>
> Well, I suppose I cannot disagree with you on that point, so yes it is
> confusing, but for sake of a solution, it is not nearly as confusing so
> long as auto ref on the parameters will behave the same for both template
> and non-template versions in a consistent way. I know auto ref on the
> return is potentially confusing, but it does increase template flexibility
> as the benefit.
>

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.

Alternatively, I think Jonathan's argument against scope ref makes perfect
> sense. Unless I misread something or he's dead wrong, how can scope be used
> without creating even more confusion? Even if scope has some properties in
> common with auto ref, it specifies something entirely different than
> accepting rvalues and lvalues. This point reminds me of why we should not
> be using bool as an integral type, it's the same reasoning.


Which argument?

Correct, it specifies something _entirely different_, it says "I can safely
receive a temporary, because I promise not to escape it". This is the
actual problem that we're trying to solve, and it addresses the problem
head on.

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.

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

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_.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130510/99669708/attachment-0001.html>