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
