Persistent list

[Timon Gehr via Digitalmars-d]

On 11/15/2015 08:57 PM, Andrei Alexandrescu wrote:
> On 11/15/2015 01:50 PM, Jonathan M Davis wrote:
>> On Sunday, 15 November 2015 at 18:09:15 UTC, Andrei Alexandrescu wrote:
>>> On 11/15/2015 01:00 PM, Jonathan M Davis wrote:
>>>> Basically, we have to decide between having physical const with the
>>>> guarantees that it provides
>>>
>>> We have that - it's immutable. -- Andrei
>>
>> Yes and no. As it stands, I can know that
>>
>> const foo = getFoo();
>> foo.bar();
>>
>> won't mutate foo unless I have another, mutable reference to foo
>> somewhere that bar somehow accessed.
>
> That is an illusion, and we need to internalize that. Consider:
>
> // inside some module
> struct T
> {
>    int[] data;
>    void bar()
>    {
>      // look, ma, no hands
>      g_data[1]++;
>    }
> }
> static int[] g_data;
> const(T) getFoo()
> {
>    T result;
>    result.data = g_data = [1, 2, 3];
>    return result;
> }
> ...


This is the exact exception he described i.e. "unless I have another, 
mutable reference to foo somewhere that bar somehow accessed."

(Also, 'bar' should be 'const'.)

> In other words, you truly need access to the implementation of getFoo()
> in order to claim anything about the changeability of stuff.

No, e.g., make either 'getFoo' or 'bar' pure.

> Note that I
> could even afford to have getFoo() return const, so no need for the
> caller to make it so!
>
> With immutable, it's all cool. Immutable data is truly immutable, and
> that can be counted on. But const, even today, cannot be assumed to be
> as strong.
> ...

This is obviously true (it is what justifies the distinction between 
const and immutable in the first place), but this is not a way to 
justify making it weaker. This is all just moving in the direction of a 
setting where all structs/classes just prevent immutable construction 
and make all member functions const, and const becomes the new mutable. 
I don't see the point.