On 7 May 2013 00:26, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
On 5/6/13 12:56 PM, Steven Schveighoffer wrote:
On Sat, 04 May 2013 22:49:42 -0700, Andrei Alexandrescu
<SeeWebsiteForEmail@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.

Yah, so that's why I'm thinking "auto ref" would fit the bill there. Requiring pointers for lvalue binding and binding loosely to ref seems like the wrong move.

... I feel like this discussion has jumped about 1 week back in time :/

In 1) "If rvalues bind indiscriminately to ref, then the call is legal because of the implicit conversion float->double"
Implicit conversion should never be allowed when receiving by ref, just like it's an error in C++. There should never be a case where, having passed an lvalue, the function receives a magic temp from an implicit conversion.
C++ correctly doesn't allow this, but lots of people here seem to think it does...

In 2) "Changing return types from ref T to T or back and expecting no ill effects (aside from fixing compile-time errors) is a frequent operation in C++ projects I'm involved in. Doing worse than that would be arguably a language design regression."
Can you show where you would ever make such a change in C++?
What do you mean by 'worse'? The behaviour is to be expected... if opIndex doesn't return a ref, why would you expect that the caller can possibly change it?
I don't see any problem here... what 'ill effects' are you referring to?
Perhaps you're arguing that the problem is that the user _isn't_ getting compiler complaints when the code is changed? The call that modifies it will still work fine, but it will obviously apply the changes to a temp that is then lost? Surely this is to be expected?