Persistent list

[Dicebot via Digitalmars-d]

On Tuesday, 17 November 2015 at 23:50:13 UTC, Timon Gehr wrote:
>> Main use case for such containers is efficient thread sharing 
>> and that
>> totally justifies specialized container (or even allocator) 
>> for each
>> dataset.
>
> Persistent containers are useful even if only a single thread 
> is involved, as they can speed up some algorithms.
>
> Having the library provide List!T, but not List!(List!T) is a 
> ridiculous situation. More generally, types shouldn't need to 
> satisfy any additional constraints (beyond abstract container 
> specific ones) to be allowed to place their instances in 
> containers.

In my opinion it is perfectly reasonable to require GC for such 
"casual" usage and require narrow specialization from RC based 
solutions. Physical immutability requires external memory 
tracking - GC provides that naturally and trying to ignore that 
fact with RC model feels like cheating yourself to me.

It may be possible to provide more generic solution if you place 
reference counting into allocator itself. But I trust Andrei 
expertise in this domain so if he decided to not pursue this 
approach there must be good reasons.

> I don't think the cases where writing a new specialized version 
> from scratch is justified are what the new container module 
> will be about.

Yes, indeed. That is why I don't think non-GC version of such 
containers belongs to such standard package at all. It is not 
worth the proposed costs.