std.experimental.collection.functional.slist

[Andrei Alexandrescu via Digitalmars-d]

On 6/18/15 6:07 PM, ZombineDev wrote:
> 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 :)

Thanks for taking a look! Yah, I, too, was a tad surprised about the 
seamless dovetailing of things.

> 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.

functional.SList should have empty but not popFront. The latter is mutating.

> * 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".

Years ago when I chose the range primitives there was a choice between:

for (auto r = x[]; !r.empty; r.popFront) {
   ... use r.front ...
}

and

for (auto r = x[]; !r.empty; r = r.tail) {
   ... use r.front ...
}

The first won, partly because it's easier to implement efficiently. So 
now we have this one mutating operation that we need to mind. Because of 
it, we'll need functional containers to be distinct from their ranges.

> * 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.

Yah, there's a little trick there that deserves an explanation - 
opAssign takes a SList by value, so the reference counting has already 
occurred at the caller side. So there's no extra need to do that, just 
move from it and leave it empty.

> * 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?

Well, it's briefer...


Andrei