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 <andrei@erdani.com>
To: Discuss the dmd beta releases for D <dmd-beta@puremagic.com>
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
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta