ref returns and properties

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> I guess I'm not really sure what the "acquire" method does.  I saw you 
> mention it in another post, but with no explanation as to what it actually 
> does, just that it was needed.  I'm sure I'm not getting what should be 
> obvious, but if you could enlighten, I would appreciate it :)

Say you have an object obj that has a Matrix property and you have a 
Matrix object handy. The Matrix is rather resource intensive so you'd 
rather not copy it unwittingly. Conventionally, if you say:

Matrix m;
... fill matrix ...
obj.matrix = m;

then m is copied into obj.matrix (there is the by-value call to set 
property). Now it's possible to arrange things such that m is 
destructively copied, but as the auto_ptr disaster has shown, it's not 
that intuitive to make assignment destroy the right hand side.

So we'd need a distinct method:

obj.matrix.acquire(m);

That method takes the matrix by reference, sucks its life out of it, and 
leaves an empty shell behind. Pretty much like in your average horror movie.

> Having the two functions seems like a reasonable baggage compromise, if you 
> want to control the get and set methods of a property and pass that control 
> to an underlying function, you need at least that.  If we start generalizing 
> it to anything, then it starts looking like struct interfaces would be more 
> suitable.  For example, you could allow setting an int property using both 
> an int and a string, do you want to pass both setters to a function?  I 
> think limiting it to just a set and a get function should be sufficient.

With only get and set I can't implement a nothrow swap, which kinda 
bends me out of shape.


Andrei