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
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
