On 6/19/15 2:36 AM, Timon Gehr wrote:
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?
Well this is a good discussion to have: should we allow rebinding (i.e.
assignment) of functional data structures or not?
For a good part of the day I've had this:
@disable void opAssign(SList);
i.e. once an SList is constructed, it'll always contain the same data.
If you need a modified list, you create another one. This is how
traditionally matters are handled in functional programming.
Later in the day I relaxed matters so assignment is allowed, provided
that other variables referring to (parts of) the same list are left
untouched. So I defined opAssign. With that, there's a possibility to
write r = r.tail, which is the moral equivalent of popFront.
So yes, if opAssign is allowed, popFront may be allowed as well. Some
may say it's another step on a slippery slope though.
comment as well. BTW: opAssign does not copy the allocator.
Fixed, thanks.
Andrei
