std.experimental.collection.functional.slist

[Timon Gehr via Digitalmars-d]

On 06/20/2015 12:24 AM, Andrei Alexandrescu wrote:
> 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,

Sorry, I wasn't clear enough, I meant append a list to a list, i.e. 
concatenation. Then you only need to duplicate the first list, and 
runtime is linear in the first list.

What I was getting at is that if things are not rebindable, you are left 
with recursive functions as the natural iteration primitive, which you 
have objected to in the past.

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

I am still similarly confused why non-rebindability is even considered.