[Dlang-study] [lifetime] Initial thoughts on lifetime management

[Andrei Alexandrescu]

On 10/28/2015 02:16 PM, Timon Gehr wrote:
> On 10/28/2015 04:07 PM, Andrei Alexandrescu wrote:
>>
>>> How does the compiler lose control with opInc/opDec? It could still fuse
>>> them.
>>
>> Fusing them relies on the compiler knowing the effects are additive
>> (three successive opInc()s mean += 3 etc) and also that opInc() and
>> opDec() cancel each other. Allowing the user to define them arbitrarily
>> prevents the compiler from doing some of these things, or limits what
>> the user can do drastically enough to just mandate one implementation.
>
> I disagree that it limits the user drastically enough to just mandate
> one implementation. E.g. (for whatever reason) a user might want to use
> reference counting with an allocator that does not allow individual
> deallocation of objects. (It is then sufficient to have only a single
> reference count, for the allocator itself.)

Point taken. The question is then whether we want to give the user 
control over individual inc/dec or only the deallocation process. The 
latter is akin to C++'s shared_ptr's deleter.

>>> How to specify the allocator for a @rc class?
>>
>> I don't know, it's a good topic for discussion. Ideas?
>
> It could be a special member that is either an alias or a reference to
> an allocator which is automatically filled by the typed part of
> std.allocator. Alternatively, one could make the references fatter and
> have an additional argument to (an overload of) opDec.

Noted, thanks.


Andrei