std.experimental.collection.functional.slist

[Ivan Timokhin via Digitalmars-d]

A couple of thoughts:

1. It seems that an allocator is a public field of SList. Should it be so? What
happens if someone changes an allocator while the list holds nodes allocated
with the old one?

2. Only dynamic allocator customisation is supported (unlike C++ containers). Is
this deliberate?

3. Shouldn't `front` functions be const?

On Thu, Jun 18, 2015 at 04:32:05PM -0700, Andrei Alexandrescu wrote:
> First pass illustrating the basic data layout:
> 
> http://dpaste.dzfl.pl/0d4a589ad6f5
> 
> Code is obviously barebones but passes tests and works with allocators.
> 
> Notes:
> 
> * I managed to not store one allocator per node, but there's one 
> allocator per range. That's needed if we want "orphan ranges" to work, 
> i.e. ranges that survive the list they came from. This is a clasic 
> convenience vs. efficiency thing.
> 
> * There's a refcount per node because any given node may belong to 
> multiple lists.
> 
> * Refcounting is interesting because many nodes are only used by the 
> previous node. So destroying a list is... funny. Never saw or wrote code 
> like this previously. See nukeTransitively.
> 
> All in all things seem convex. Please destroy appropriately.
> 
> 
> Thanks,
> 
> Andrei