rvalue references

[bitwise via Digitalmars-d]

On Wed, 03 Jun 2015 03:09:06 -0400, Namespace <rswhite4 at gmail.com> 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.


Hmm.... Indeed. It seems I misunderstood DIP25. I didn't think that was  
allowed.

It appears that even this is allowed:

private Texture* _tex;
struct Sprite {
     this(ref Texture tex) {
         _tex = &tex;
     }
}

Is DIP25 intended to eventually prevent these examples?

Wouldn't it have made more sense for DIP25 prevent _all_ escaping,  
including pointers? or is that not possible?
Then, instead of 'return ref' it could be 'escape ref' or something.
Anyways, moot point I suppose.

   Bit