The liabilities of binding rvalues to ref

[Manu]

On 9 May 2013 17:26, Peter Alexander <peter.alexander.au at gmail.com> wrote:

> On Thursday, 9 May 2013 at 04:00:55 UTC, Manu wrote:
>
>> 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?
>>
>
> The call will not still work fine in C++.
>
> Here's the code again:
>
>
> class Collection(T) {
>   ref T opIndex(size_t i) { ... }
>   ...
> }
>
> void fix(ref double x) { if (isnan(x)) x = 0; }
>
> void fixAll(Collection!double c) {
>   foreach (i; 0 .. c.length) {
>     fix(c[i]);
>   }
> }
>
>
> In (analogous) C++, if Collection's opIndex changes to return by value
> then the call to fix is a compile time error (the rvalues don't bind to
> unqualified ref). I believe Andrei is arguing that D must _at least_ do
> this to make progress, i.e. not be "worse" (than C++).
>

Ah yes, right, C++ fix() would need to be 'const ref&', but we decide in D
that 'ref const()' is too restrictive.

We're about 1 post away from finding ourselves arguing over 'scope
ref'/'auto ref' again...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130509/f6298f23/attachment.html>