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