std.experimental.collection.functional.slist

[Andrei Alexandrescu via Digitalmars-d]

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