speaking as a lay user - if this is going to be done maybe it should something like __gconst? similiar to __gshared which is ugly enough to make you concider not using it, but it's there if you really need it.
On Wed, Feb 17, 2016 at 5:29 AM, Marc Schütz via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > 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
