rvalue references

[via Digitalmars-d]

On Wednesday, 3 June 2015 at 07:09:09 UTC, Namespace wrote:
> On Wednesday, 3 June 2015 at 03:57:38 UTC, bitwise wrote:
>> I forgot to mention, in terms of this statement I made:
>>
>>> I can't remember right now what the reasoning was for 'const 
>>> ref' not to take
>>> rvalues in the first place. I think it was that you could 
>>> escape the reference,
>>> but this isn't true anymore with DIP25 right?
>>
>> I think someone brought this up about a weeks ago,
> That was me.
>> and this was Andrei's response:
>>
>>> Knee-jerk response: if no "return" attribute on a function it 
>>> should be safeto bind rvalues to ref parameters. Of course 
>>> that's impractical as a default
>>> so explicit "auto ref" would be needed. -- Andrei
>>
>> What's impractical?
>
> It's dangerous. If rvalues could be passed to normal ref 
> parameter we would have a problem. Consider this:
>
> ----
> struct Sprite {
>     private Texture* _tex;
>
>     this(ref Texture tex) {
>         _tex = &tex;
>     }
> }
> ----
>
> This works because we accept a valid lvalue and store a pointer 
> to it. If the CTor would accept also rvalues, then the pointer 
> would be invalid, since the texture was just a temporary 
> variable. Not the best example, but I think you understand what 
> I mean.

This code needs to be disallowed under DIP25 (or whatever the 
final DIP will be), of course.