The liabilities of binding rvalues to ref

[Manu]

On 7 May 2013 00:26, Andrei Alexandrescu <SeeWebsiteForEmail at 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 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.
>>
>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130509/8b914340/attachment-0001.html>