ref returns and properties

[Andrei Alexandrescu]

Denis Koroskin wrote:
> On Mon, 26 Jan 2009 00:59:32 +0300, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Jarrett Billingsley wrote:
>>> On Sun, Jan 25, 2009 at 3:00 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>> 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.
>>>  I absolutely wouldn't.  Once we start doing stuff like that, we start
>>> getting into tedious C++ territory.  Holding the compiler's hand,
>>> writing mountains of tedious, easy-to-mess-up boilerplate code, just
>>> to be able to implement simple things so they fit in with the
>>> language's weird semantics.  At that point I'd _rather_ use the
>>> current "properties."
>>
>> But you lose correctness and efficiency. I agree that in certain cases 
>> they aren't paramount, but you can't build a language to not allow them.
>>
>> A possible solution would be to require only get, make acquire 
>> necessary only for writable properties, and make release entirely 
>> optional.
>>
>>
>> Andrei
> 
> 
> get/set/free?

With these you can't move a resource inside the property.

Andrei