std.experimental.collection.functional.slist

[Timon Gehr via Digitalmars-d]

On 06/19/2015 04:24 AM, Andrei Alexandrescu wrote:
> On 6/18/15 6:26 PM, ZombineDev wrote:
>> On Friday, 19 June 2015 at 01:07:10 UTC, ZombineDev wrote:
>>> On Thursday, 18 June 2015 at 23:32:03 UTC, Andrei Alexandrescu wrote:
>>> [..]
>>
>> I also noticed that the `front` primitive returns only `const ref`
>> (instead of `inout ref`). Is this because the user should regard the
>> SList as immutable - i.e. if you want to change an element, you have to
>> make the modification in a copy of the list, instead of doing it inplace?
>
> Yah, traditionally functional data structures don't allow their clients
> to mutate the data AND the topology of the container. So front() returns
> a non-mutable ref.
>
> It might be interesting to explore containers that allow mutation of
> data but not of topology. We may collectively think of a few
> applications of that. For now I went the traditional route.
> ...

That's not the issue. The data held by the structure shouldn't be 
mutated, since it is persistent. Returning const(T) means that the data 
that the return value refers to may not be mutated. This is crippling.

BTW: sharing of structure between instances is the main motivation for 
persistent data structures. opAssign shouldn't move.
(opAssign should never move, assignment is not the same as a move.)