Disallowing property results to bind to ref is not a good solution IMO. Note
that one of the *worst* problems with rvalue/lvalue ref semantics right now is
operator overloading. Frequently, one may want to pass by ref for overloading
arithmetic operations or other operators due to the size of the struct. But
then simple combining operations like a + (b - c) don't work.
Note that this varies *greatly* with the issue of the compiler doing implicit
casting. In the compiler's case, it's creating behind-the-scenes temporaries
that you cannot see or access. But in the case of the return value of a
function or property, everything is spelled out in the declaration of the
function or property.
I think part of our issue here is, there are multiple reasons to pass by ref.
So it's difficult to establish the correct rules.
My thought is, we need different markers for different situations. I don't
think one keyword is enough.
What 'auto ref' was supposed to do was allow both rvalue and lvalue binding.
However, maybe it's lvalue-only binding which is the less common beast? What
about ref taking both rvalues and lvalues (unless a non-ref overload is
present) and something else designating that lvalues are the only acceptable
binding?
Regardless of the solution, I think we need to designate two different
situations:
1. I want to pass this by reference because it's more efficient
2. I want to pass this by reference because I want to change it.
And I really can't see any way the compiler can infer one over the other.
-Steve
>________________________________
> From: Andrei Alexandrescu <[email protected]>
>To: Discuss the dmd beta releases for D <[email protected]>
>Sent: Thursday, April 12, 2012 5:50 PM
>Subject: Re: [dmd-beta] rvalue references
>
>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.
>
>So we don't want to allow function results (including property results) to
>bind to ref parameters.
>
>
>Andrei
>
>_______________________________________________
>dmd-beta mailing list
>[email protected]
>http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
