Helping with __mutable (which will be renamed to __metadata)

[Timon Gehr]

On 15.04.19 06:05, Doc Andrew wrote:
> 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?
> ...

Yes. Also, it means we don't reserve a previously unreserved identifier.

> 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).
> ...

It's not the same.
> 
> 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;
>      }
> }
> ...

Is your suggestion just to make __metadata imply private, or is there 
anything else you are trying to say?

> 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

Storing the data within the object is the point. As the original post 
states, the motivation for the DIP is to allow memory allocation schemes 
such as reference counting, as well as lazy initialization to be 
implemented for `immutable`-qualified data structures. The mutability is 
supposed to be an implementation detail -- from the outside, the data 
will still appear to be `immutable`. (The current version of the DIP 
completely misses this point though, leaking __metadata into the type 
system.) Compiler optimizations can change the semantics of code that 
operates on __metadata. (e.g., if it is able to elide a read to a 
lazily-initialized field, that field will not be initialized, if it 
elides a reference copy, the reference count does not need to be 
updated, etc.) Therefore, modifications of __metadata need to be 
consistent with rewrites that are valid for strongly pure functions.