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