Persistent list

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 16 November 2015 at 09:04:33 UTC, Joseph Cassman wrote:
> Just as a side thought, although it is probably a bit of a 
> dasoku. But I have always wondered that if the purpose of 
> _const_ is to allow some data to be changed by one reference 
> but not changed by another, then why is it transitive. Doesn't 
> that defeat its purpose?

The D designers might want to look at Pony lang's capability 
system, which has been proven sound. It has 6 different aliasing 
capabilites that regulates among other things transition from 
mutable to immutable.

D is a little bit better of (if it does not allow casting away 
const) than C++, because in C++ const is essentially "shared 
const", whereas in D in is "local const with potential aliasing". 
AFAIK the D sementics is that no other thread can hold a mutable 
reference to something you have as const. But it is still a 
relatively weak guarantee. In C you have "restricted" for 
notifying the compiler that the resource is aliasing free within 
the context.

> And then doesn't transitive const effectively have the same 
> semantics and use-case as _immutable_? I mean, once you start 
> to use transitive const in an interface, how are you supposed 
> to get the mutable reference that is so promised? Perhaps this 
> is the question that is essentially being asked here?

The right thing to do is to:

1. map out all possible aliasing combinations and pick a set of 
capabilities that is sound

2. poke a clean well defined hole through the constness by 
allowing a "mutable" modifier that does not depend on type state. 
(or you should add type state and an effect system).

3. implement something that is compatible with conservative C++ 
(shared head const with mutable fields and no const_cast).

D really should try to avoid repeating C++'s mistakes or add a 
different set of mistakes, in order to compensate for former 
mistakes.