On Wed, 03 Jun 2015 03:09:06 -0400, Namespace <rswhi...@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
