ref returns and properties

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> 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.

So what you are saying is that you want to control the set such that it 
destroys the source (essentially, I'm reading, you don't want to do a deep 
copy, just a reference copy, and then null the original reference).

Let me ask another question then... does a property have reason to have both 
set AND acquire?  More specifically, does a function that takes a property 
as an argument as we have been discussing need both set and acquire passed 
to it?  If not, you can simply pass the set method that you want, still only 
requiring a pair of functions.  How to signal that to the compiler easily? 
Not so sure... but it does seem to me like a type should know how it should 
be copied, and likely doing it other ways should require special methods.

I can think of possible library solutions to this, say a wrapper property 
struct that can call any two functions to do set or get.

>
>> 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.

Sorry, don't get that either.  Why can't set and get be used in a nothrow 
swap?

-Steve