The liabilities of binding rvalues to ref
Steven Schveighoffer
schveiguy at yahoo.com
Mon May 6 09:56:11 PDT 2013
On Sat, 04 May 2013 22:49:42 -0700, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> void fix(ref double x) { if (isnan(x)) x = 0; }
...
> There may be other important patterns to address at the core, please
> chime in. I consider (1) above easy to tackle, which leaves us with at
> least (2). My opinion is that any proposal for binding rvalues to ref
> must offer a compelling story about these patterns.
But there are reasons to bind rvalues to references. I think deadalnix
said it best, when you want to use ref to modify values, generally you
want rvalues to be rejected (though I think rvalue is not a good
description, consider that a pointer is an rvalue, but what it points to
is an lvalue). When you want to use ref to avoid expensive copies, you
want rvalues to be accepted.
So I agree with your solution to 1.
For 2, I think it's not so simple. A possible solution is to make fix
accept a pointer, which is an explicit reference and would not bind to
rvalues. In @safe code, a pointer could be allowed, just pointer
arithmetic disallowed. In addition, Peter's case makes this even more
disruptive. 'this' must accept rvalues, so it's not possible to eliminate
the problem by preventing binding.
-Steve
More information about the Digitalmars-d
mailing list