[dmd-beta] rvalue references

Dmitry Olshansky dmitry.olsh at gmail.com
Thu Apr 12 15:16:42 PDT 2012


On 13.04.2012 1:50, Andrei Alexandrescu wrote:
> On 4/12/12 3:11 PM, Dmitry Olshansky wrote:
>> Interesting thing with non-escaping ref is that making truly unsealed
>> containers is hard while writing sealed ones made easier(and that's a
>> good thing btw).
>
> There is a liability here however. Today, people who don't want to 
> allow changes to their containers or ranges would routinely return 
> rvalues from e.g. front().
>
> If we allow function results to bind to ref parameters, people would 
> think they modify stuff when in fact they don't do anything. Consider:
>
> void swap(T)(ref T lhs, ref T rhs);
> ...
> swap(r1.front, r2.front);
>
> The user thinks the fronts of the ranges are swapped but nothing happens.
>
I agree with the problem. Yet when you pull out an atomic bomb to solve 
it I humbly take out a scalpel.
The problem is with swap - it is meaningless for rvalues. Solution? Just 
declare this very same intent:

void swap(T)(T lhs, T rhs){
     static assert(false, "swap of rvalues has no effect");
}

void swap(T)(ref T lhs, ref T rhs);
{
... //same trustworthy swap
}

> So we don't want to allow function results (including property 
> results) to bind to ref parameters.
>
???
I really don't get this at all. Cripple the proposal at its best? And 
how it's different from:

swap(+a.b, +func()); // it's meaningless because it's _swap_, i.e. it's 
semantic side of things tied to' swap'

> -- Dmitry Olshansky


More information about the dmd-beta mailing list