std.experimental.collection.functional.slist

[Timon Gehr via Digitalmars-d]

On 06/19/2015 04:21 AM, Andrei Alexandrescu wrote:
> ...
> functional.SList should have empty but not popFront. The latter is
> mutating.
> ...
> 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.
> ...

This is one reason why I dislike the term "functional" in this context, 
it implies unnecessary baggage. popFront does not affect any other 
references to the same data, so why is there any problem with it?

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

Oh. Well, disregard my comment about the moving, got distracted by the 
comment as well. BTW: opAssign does not copy the allocator.

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

And "wrong".