Head Const

[Danni Coy via Digitalmars-d]

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 at 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