Rebooting the __metada/__mutable discussion

[Zach Tollen]

On Friday, 8 April 2022 at 17:28:30 UTC, Timon Gehr wrote:
> On 08.04.22 17:07, Zach Tollen wrote:
>> On Friday, 8 April 2022 at 08:23:34 UTC, Timon Gehr wrote:
>>> Yes. I do not understand why so many people are so keen to 
>>> conflate entirely different things into the same concepts. 
>>> That's just bad language design.
>> 
>> No it's not.
>
> Of course it is. It hampers expressiveness while adding 
> incidental complexity. Lose-lose.

Wrong. Simplicity is fine when it allows you to do what you want 
without forcing you to do what you don't want. If what you say 
were true, then D should have adopted every single built-in 
attribute and every type qualifier which has ever been suggested, 
because the lack of them would "hamper expressiveness."

The incidental complexity of a given multi-purpose feature only 
arises when the one purpose of the feature simultaneously makes 
another purpose of the same feature difficult to achieve. I do 
not consider this an inevitable outcome. I want to examine the 
specific case instead.

>> But it's also bad language design not to be open to the 
>> possibility of a conflation of different things which ends up 
>> being harmonious and easy to explain.
>
> That's just never how it works out. You should only conflate 
> things that are actually the same thing.

The use cases of DIP1035, for the most part, are a strict subset 
of the uses of `__mutable`/`__metadata`. It is agreed that you 
can only access `__metadata` variables from `@system` code. 
Therefore by implementing `__metadata` you basically get DIP1035 
for free. My proposal is simply to use DIP1035's word `@system` 
two encompass the two ideas.

The purpose of DIP1035 is to be able to force a variable to be 
considered unsafe, because it is already being used in an unsafe 
way. If you're trying to decide whether merging `@system` and 
`__metadata` is a good idea, you would first need to come up with 
a use case proving a possible conflict of purposes as follows:

You would need to show how marking a variable `@system` because 
it is *already* being used dangerously might then lead to it 
being used dangerously *differently*, but now in an unintended 
and undesirable way, solely because before, when it was used 
dangerously, it was immutable.

It seems like a really tall order to me. And if you can't provide 
an example like that, then on what basis can you say that these 
two features can't be combined?

My main point is that mutability, in nearly all cases, is 
precisely what would motivate a variable to require being marked 
`@system`. As to global data which is initialized to unsafe 
values and therefore inferred `@system`, I don't even know what 
these would be for. They seem like they would always be bugs to 
me.