Head Const

[Dicebot via Digitalmars-d]

On 02/16/2016 09:29 PM, Marc Schütz wrote:
> The last sentence in my post is crucial: "keep most of the existing
> guarantees". If we can ensure that access to @mutable data is strongly
> restricted and properly encapsulated, we don't lose anything. The type
> system would stay as it is, there would just be a way for it to be
> broken locally without provoking undefined behaviour.

One example of a existing guarantee you won't be able to keep, for
example, is that any immutable allocation can be completely put into
separate read-only memory. A very important property for building
optimized allocators if you keep in mind sharing goals of immutability.

> For example, it's always possible to use a global mutable associative
> array to store additional data connected with an immutable or const
> object (ignoring purity issues for the moment). That's safe because from
> the outside, there's no observable change to the state of the object
> itself, and the global AA's type (shared/thread-local) prevents race
> conditions.

Yes and this is how I believe it must be done.

> There's no reason why we can't have the same guarantees for embedded
> members, without resorting to an external AA. Have a look at my DIP [1]
> for lazy initialization of const members, which I now realize can be
> adapted to this use case. Basically, just replace `lazy` by `@mutable`,
> and most of the DIP is still valid. I'll try updating it when I find the
> time.
> 
> [1] http://wiki.dlang.org/DIP85

The problem with this DIP is that it speaks about type system semantics
and what matters first is memory model (which is currently very
under-defined as soon as you step from a "the GC" world).

Physical immutability is demanding but it also has great value in its
simplicity and being hard to fool. Any language change that is going to
reject this notion has to be really strongly justified in terms of what
is gained and what is lost and not come simply because expressing such
semantics is possible.