std.experimental.collection.functional.slist

[ZombineDev via Digitalmars-d]

On Thursday, 18 June 2015 at 23:32:03 UTC, 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

It's a nice start and I like in general how easy it is to 
integrate an allocator to the design. The node ref-counting and 
disposal make this almost a classic text-book example - it's that 
easy :)

I have some comments/questions:
* I don't know if it's because this is WIP, but it also strange 
that the range has empty and popFront primitives, but the Slist 
doesn't have them.
* More over, the distinction between the SList collection and 
it's range is a bit blurry. They even have the same members. You 
have named your module
std.[..]functional.[..], which makes me wonder if you actually 
need a collection to operate with such lists. This idea reminds 
of programming lisp where operations with lists are fluid and 
everything is floating around and it just works without having to 
call collection<T>.push_back(elem); a single-time. The difference 
being that this is GC-free and with more deterministic behavior, 
but it still resembles this productivity of "just get stuff done 
and don't bother me with management".

* It's strange that the copy-constructor `this(this)` has 
reference semantics (it adds reference to the list) and the 
assign-operator (opAssign) has move semantics (it steals the 
contents of the victim on assignment).
Edit: actually because Slist is a struct this line doesn't do 
anything to the moved from list: 
http://dpaste.dzfl.pl/06e24fecd2da#line-93 , though to the 
comment in the function is a bit disorienting.

* In a couple of places like this: 
http://dpaste.dzfl.pl/06e24fecd2da#line-181
you assert that the list is non-empty. Why don't you instead use 
in contracts?