Persistent list

[Jonathan M Davis via Digitalmars-d]

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. And if bar is pure, and I 
didn't pass another reference to foo in via one of the function 
arguments, then I know that foo won't have been mutated by bar. 
The same goes if I foo was created inside the current function 
and had no chance to be assigned somewhere where bar could get at 
even if it weren't pure. It's only when an object gets passed 
around a bit that there's really even the possibility that it 
will be mutated by a function that treats it as const, and the 
combination of TLS and pure reduces that risk considerably. So, 
in general, you really can rely on a const object not being 
mutated when you call a const member function or even pass it to 
a function which takes it as const.

However, if we make it so that casting away const and mutating is 
defined behavior or allow any other kind of backdoor to const, 
then all bets are off. Without looking at the implementation of 
every function that an object gets passed to, you can't know 
whether it's actually being mutated or not even though it's 
const. So, where's a definite loss there. Putting backdoors into 
const costs us the guarantees that we get with const now. We go 
from treating const as physically const to treating it as 
logically const (and logically const can't actually be guaranteed 
by the compiler).

Now, that puts us in a place that's similar to C++, and that 
works, but it definitely does not provide the same guarantees 
that we have now and is worse in the cases where backdoors aren't 
needed.

- Jonathan M Davis