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