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?
