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.
