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.
