ref returns and properties

[Andrei Alexandrescu]

Michiel Helvensteijn wrote:
> Andrei Alexandrescu wrote:
> 
>> void move(ref T src, ref T dst);
>> void swap(ref T lhs, ref T rhs);
>>
>> ...
>>
>> But if "prop" is a property with get and set, everything falls apart.
>> Properties effectively hide the address of the actual data and only
>> traffic in values. That's often good (and sometimes even the only
>> possibility in the case of properties computed on-the-fly), but this
>> abstraction effectively makes resource-conserving move and swap
>> impossible.
>>
>> ...
>>
>> What to do? I'd like to refine the notion of property such that moving
>> properties around is possible, without, however, complicating their
>> interface too much.
> 
> I posted a possible solution to this (I think) in the last properties
> thread. I was thinking that properties might be equiped with extra member
> functions. One advantage is that you might get more efficiency. I think you
> just named another.
> 
> class Host
> {
>      property prop
>      {
>          T get() { ... }
>          void set(T value) { ... }
>          void move(ref T dst) { ... }
>          void swap(ref T rhs) { ... }
>      }
> }

But these are too many. These should suffice:

class Host
{
      property prop
      {
          T get();
          void acquire(ref T value) { ... }
          void release(ref T value) { ... }
      }
}

set() can be implemented as acquire from a copy, and swap can be 
implemented by calls to acquire and release. Technically, get() could be 
also implemented with acquire and release, but that's too intensive for 
most types.

The problem I'm seeing is that most people won't want to go through the 
trouble of implementing three functions for one property.


Andrei