[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