Rebooting the __metada/__mutable discussion

[Zach Tollen]

On Sunday, 10 April 2022 at 14:34:41 UTC, Timon Gehr wrote:
> You seem to be contradicting yourself. It's either bad logic or 
> bad communication.

I think it's the latter. I think the chief source of bad 
communication is actually a design flaw in DIP1035:

https://forum.dlang.org/post/tgbwhgxzkrupdotylkms@forum.dlang.org

`@system` variables are not a bad idea. DIP1035's mistake is in 
thinking that anyone would ever want a `@system` variable by 
accident.

Once you subtract all of the evidence against me which relied on 
the design flaw in DIP1035, what part of your case still stands?

All of the actual use cases for `@system` variables — I mean real 
`@system` variables, not just unsafely initialized ones — that I 
have seen (some are illustrated in the DIP, but also in Steven 
Schveighoffer's really excellent 
[presentation](https://youtu.be/O3TO52rXLug) on tagged unions) 
involve preserving the invariant of a data structure by making 
sure the `@system` variable is only modified simultaneously with 
some other piece of data.

Which means, generally, they are modified along with a normal 
variable. If the `@system` variable had `__mutable` 
characteristics implicitly, the `@system` function in which it 
was modified would also be modifying a non-`__mutable` value. 
Such a function would error anyway.

Maybe there is some other natural use for `@system` variables. 
But none of the use cases I have seen seem particularly 
incompatible with the additional `__mutable` functionality.

> You are basically stating that you will not move away from your 
> position, no matter what.

All I'm doing is trying to make my position clear.

You have to consider everything I've been saying in the context 
of how `@system` variables *should* have been defined from the 
beginning — as always explicitly `@system`. (I didn't realize 
just how devastating DIP1035's alternative, "infer `@system` 
everywhere" design really was until I was forced to examine it 
more closely. I've now made my case about that in the other post.)

This goes for everything I've been saying. Apply the new filter 
of: "A variable is a `@system` variable iff it is explicitly 
marked `@system`."

Me:
>> Again, the only question is whether having `__metadata` 
>> functionality will cause intractable pain to the use cases of 
>> `@system` which don't require it.
>> 
>> The solution to our debate — insofar as my claims deserve any 
>> merit at all — is to implement both DIP1035 and the 
>> `__metadata` DIP, with the additional requirement that all 
>> uses of `__metadata` be marked `@system` as well.

I stand by this statement, assuming modified DIP1035.

> In other words, you will just move the goalposts until you can 
> claim you were right.

I honestly don't think that's what I'm doing. My mistake was 
actually having too strong a sense of the *right* way to 
implement `@system` variables. I only realized too late that 
DIP1035 wasn't quite there.

--

I'm sorry for a lot of the stress I've caused. I'm pretty sure 
that everything I've been saying makes at least a little bit of 
sense, given what I have always meant (to myself at least ^_^) by 
"`@system` variable".

Zach