ref returns and properties

[Yigal Chripun]

Jacob Carlborg wrote:
> Andrei Alexandrescu wrote:
>> 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
>>
>
> What about this:
>
> class Host
> {
> property acquire release prop
> {
> T get();
> }
> }
>
> And then the compiler will automatically created the "acquire" and
> "release" methods.
>
> There could also be what I would like to call "property shortcuts" (ruby
> calls this attributes) like this:
>
> class Host
> {
> get acquire release T prop;
> get set T prop2;
> }

I agree with Daniel and I think that 99.999% of users will use 
properties with just get/set methods and those should be the methods for 
defining properties, _not_  acquire/release as above. the other 0.001% 
can just define extra functions in the body of the property. The design 
should be geared towards the common and simple case.