std.experimental.collection.functional.slist

[via Digitalmars-d]

On Friday, 19 June 2015 at 15:55:48 UTC, Andrei Alexandrescu 
wrote:
> On 6/19/15 8:27 AM, 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?

Hard to come up with a convincing example here. Any large 
function that creates a data structure

     auto lst = SList!int(1, 2, 3);

features some non-trivial logic

     if (lst.length % 2)
     {
         lst = lst.tail();
     }

and produces whatever result

     writeln(lst);

is much simpler to reason about if the variables are all const, 
aka not assignable. The above is obviously weak. The only 
convincing argument I know of is to use a language that enforces 
immutability and experience the lift of a mental burden.

Erlang uses single assignment, a variable can only be bound once.

The obvious counter argument seems to be performance.

>
> FWIW Scala's immutable containers are all assignable. -- Andrei

Not knowing scala at all, to me this looks insane:

http://www.scala-lang.org/api/2.11.5/index.html#scala.collection.immutable.Vector

There is a little too much.