Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/25/2015 08:33 PM, Andrei Alexandrescu wrote:
> On 10/24/2015 07:03 PM, Timon Gehr wrote:
>> On 10/24/2015 09:22 PM, Andrei Alexandrescu wrote:
>>> On 10/24/15 3:19 PM, Timon Gehr wrote:
>>>> Even if this was possible, it would not be a very good idea. Persistent
>>>> data structures have use cases that would be hindered by required
>>>> transitive immutability.
>>>
>>> This part I don't quite get.
>>
>> The slots are not mutable, but they are not /transitively/ immutable
>> either. Note that this does not require any special effort, nor does it
>> /prevent/ stored elements from being (transitively) immutable. Scala
>> does it this way. (Haskell as well, basically.)
>
> I see. Well, this will be unpleasant to implement in D.
>
> One simple way to do so would be to have accessors return rvalues:
>
> T front() { ... }
>
> Then you get to change the indirections of T, if any, but not what's
> stored in the container directly.
>
> Problem is accessing every element by rvalue is likely to be inefficient
> in the general case (even on data without copy ctors).
>
>
> Andrei
>

As I mentioned, the cheap way out for performance would be to provide 
what you suggested (persistent topology, arbitrary reference access to 
slots). Users can then use type qualifiers at their own discretion. 
There could probably even be short aliases to automatically have 
immutable elements. What's important is that use cases for mutable 
elements are not ruled out. They don't necessarily need to be on the 
path of least resistance.