Helping with __mutable (which will be renamed to __metadata)

[Doc Andrew]

On Sunday, 14 April 2019 at 00:38:16 UTC, Timon Gehr wrote:
> On 14.04.19 02:19, Suleyman wrote:
>> On Saturday, 13 April 2019 at 08:58:06 UTC, Timon Gehr wrote:
>>> Won't happen, because data with __metadata annotations inside 
>>> will not be put in read-only memory. (This can be known 
>>> statically.)
>> 
>> If it's adding these kinds of protections then I think it 
>> would be worth it and a step forward in making D more safe. 
>> you might also consider the 'shared' protection I mentioned 
>> earlier then maybe you can lift the restriction on 
>> modification in @safe code.
>
> I don't think it should be @safe. Rather, `pure` and 
> `immutable` should retain their meanings, which implies that 
> there are wrong ways to use `__mutable` (hence unsafe), and 
> there are still non-cosmetic reasons to use `immutable` even if 
> there are `__mutable` fields.

A few questions/thoughts (or at least food for thought for others 
more informed than me):

1. Maybe it's just me, but why the leading underscores? I'm 
wondering if this is because it's a scary/ugly-on-purpose feature 
like __gshared that is intended only sparingly?

1b. A lot of people have been clamoring for immutable by default, 
might keeping the DIP's original annotation "mutable" (with no 
underscores) make this a step in that direction? (with all the 
baggage and argument that carries with it, which is out of scope 
for this discussion).

Later on, if the "mutable" qualifier is desired, we aren't 
carrying around both mutable and __mutable, or __mutable and mut 
or whatever ends up being the flavor of the day.

1c. Having said that, I think the "mutable" discussion and the 
"metadata" discussion are two separate things - which I think 
Andrei alluded to in the keyword change - this is potentially 
much bigger than just short-circuiting Immutability for a good 
cause.

2. If the __metadata qualifier can only be applied to private 
fields, and carries special semantics w.r.t. escaping the type 
system, is there any benefit to treating it more like a 
visibility attribute?

struct something
{
     metadata        // maybe type qualifiers disallowed in here
     {
         int a;
     }
     private
     {
         int b;
     }
     public
     {
         int c;
     }
}

And... maybe metadata shouldn't be stored with the object at all? 
This way, it doesn't affect the layout of the object in memory, 
and doesn't require the need to short-circuit the type system if 
a later use of the class is marked Immutable. The object's 
metadata lives, not sorta-outside the type system, but outside 
the object itself? There are some challenges I can think of with 
this approach that I can expand on, but also some benefits.

-Doc