Persistent list

[Timon Gehr via Digitalmars-d]

On 11/17/2015 02:38 PM, Dicebot wrote:
>
>> Anyway, any design that does not allow e.g. nested lists is inadequate
>> IMO.
>
> But here I have to disagree. There simply isn't anything generic in
> immutable containers with RC, each requires own tweaked solution. It all
> works nice with GC because all memory tracking becomes exclusively
> external - trying to ignore and hide that fact makes no sense to me.
>
> 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.

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.