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.
