Rebooting the __metada/__mutable discussion

[Zach Tollen]

On Saturday, 9 April 2022 at 17:22:38 UTC, Timon Gehr wrote:
> Your proposal is not simpler.

It is simpler. The only question is whether that simplicity comes 
at too high a cost.

> Your proposal fails to meet your own standards.

I don't know if it meets my standards or not. I would need an 
example where a variable which was either explicitly marked, or 
inferred `@system`, and implemented as desired with that label, 
then changed its behavior as a result of also implicitly having 
the privileges of `__mutable`.

> I see what you did there. I can do that too: Clearly you think 
> that simplicity and expressiveness are both monotone functions 
> of the number of attributes that are in the language. If what 
> you say were true, we should conflate @safe and pure, as well 
> as @nogc and nothrow because that would be "simpler". That's 
> ridiculous!

No I'm saying that simplicity and expressiveness are tradeoffs. 
The Go language, for example, traded a lot of expressiveness for 
simplicity. That doesn't make it bad language design. It means 
they weighed the pros and the cons, and they made a decision.

>> The use cases of DIP1035, for the most part, are a strict 
>> subset of the uses of `__mutable`/`__metadata`.
>
> ???

All `__metadata` variables qualify as DIP1035 `@system`. If you 
added `@system` to any instance of `__metadata`, it would have no 
effect. Therefore, if only `__metadata` were implemented, users 
could utilize it to achieve the intended goals of DIP1035. (Just 
allow them to mark it wherever they wanted instead of confining 
it to aggregate members, even though most of the use cases are in 
fact aggregate members.) The question is simply whether 
additionally being able to violate the type system would cause 
intractable problems. I don't know. I suspect that almost all use 
cases of `@system` are mutable to begin with. And if they 
weren't, I would have to look the workarounds, to see if issues 
of having undesired `__metadata` functionality caused more pain 
than the simplicity of using only one keyword merited.

> So your proposal is...

My proposal is to take everything DIP1035 marks or infers as 
`@system` and extend `__metadata` functionality to it. This may 
sound dangerous. The logic is simply that this is `@system` code, 
and `@system` code is dangerous. But it is also powerful. That's 
the overarching idea. Both dangerous and powerful. (D should also 
be working towards `@safe` by default, of course.)

Again, the only question is whether having `__metadata` 
functionality will cause intractable pain to the use cases of 
`@system` which don't require it.

> In any case, even if your proposal was simple to state 
> formally, it would still lead to really bad outcomes.

The difference between us is that you are sure of that, and I am 
not.

> To the extent that I can make sense of your paragraph, it's 
> very easy and Paul has already done it.
>
> NB: I really dislike it when some people go from "there are no 
> counterexamples" to "there is exactly one counterexample and I 
> don't care about that particular one" after they have been 
> presented a counterexample to their claims. It makes me not 
> want to engage with their posts anymore. It's so disrespectful 
> to other people's time. If you thought there were no 
> counterexamples and were presented one, chances are that you 
> also missed other things.

Give me an example of a global variable which is intended to be 
immutable, and which is also initialized to point to undefined 
memory, which isn't a bug. assuming it's not a bug, since it is 
meant to be immutable, then this is one case where the conflation 
of `@system` and `__metadata` might be risky. The case could be 
ameliorated by the fact that you can't access it in `@safe` code. 
What I'm saying is that I suspect actual cases of this will be 
rare, that they may not outweigh the benefits of having a very 
simple system, with one keyword to encompass all unsafe activity.

> ...

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. Semantically, it would 
change nothing, and it would actually be easier to understand for 
newcomers.

Then, five years later, to test my theory, add a compiler switch 
`preview=deprecate__metadata`, put the `__metadata` functionality 
into the `@system`, and make `__metadata` a no-op.

If nothing breaks, I was right. If something breaks, and the 
workarounds aren't seamless, then you were right.

Zach