Head Const

[Marc Schütz via Digitalmars-d]

On Tuesday, 16 February 2016 at 13:35:56 UTC, Dicebot wrote:
> On 02/16/2016 02:49 PM, Marc Schütz wrote:
>> `@mutable` OTOH would be a useful for both C++, reference 
>> counting, caching, lazy initialization... But we need to find 
>> a way to keep most of the existing guarantees, especially 
>> concerning shareability.
>
> In my opinion @mutable would be a disaster of much higher 
> destructive impact than head const. I am very opposed to it no 
> matter how it is designed. Once you start considering it, you 
> are better at simply throwing away existing const system and 
> starting it all from scratch with D3. Logical const is harmful 
> as it doesn't give and serious guarantees but gives developer a 
> false sense of confidence.

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.

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.

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