std.experimental.collection.functional.slist

[Andrei Alexandrescu via Digitalmars-d]

On 6/19/15 2:44 PM, Timon Gehr wrote:
> On 06/19/2015 11:37 PM, Timon Gehr wrote:
>> On 06/19/2015 05:27 PM, Andrei Alexandrescu wrote:
>>> On 6/19/15 8:01 AM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?=
>>> <kuettler at gmail.com>" wrote:
>>>> If opAssign is allowed, a major point of functional data structures is
>>>> lost. Client code is so much better if rebinding is off the table.
>>>
>>> I have the same instinct but not enough rationale. What would be an
>>> example in favor of the argument?
>>
>> I think he is just arguing for immutable by default. The obvious
>> counter-argument is: Show me the implementation of the
>> 'length(T)(SList!T)' function for SList!T with disabled opAssign.
>
> Bad example, you'd just use the range, I guess. :o)
> Append?

Appending to a functional singly-linked list would necessitate wholesale 
duplication, whether or not the list has mutable elements. Indeed if the 
reference count is 1 for _all_ elements in the list, there's no need for 
copying. That takes O(n) time to evaluate, but walking through to the 
end of the list is needed anyway.

But that's due to the topology of the list. You can append to a slice of 
immutable objects no problem (we do that with strings all the time).

I still am confused as to where your vision aims; I'll reply to your 
other message.


Andrei