Rebooting the __metada/__mutable discussion

Zach Tollen zach at mystic.yeah
Sun Apr 10 03:42:38 UTC 2022


On Sunday, 10 April 2022 at 00:04:43 UTC, Zach Tollen wrote:
> On Saturday, 9 April 2022 at 17:22:38 UTC, Timon Gehr wrote:
>> So your proposal is...
>
> My proposal is to take everything DIP1035 marks or infers as 
> `@system` and extend `__metadata` functionality to it.

I should amend my proposal to say I don't really think anything 
should be inferred to have `__metadata` functionality. (That's 
going too far even for my bold mind!) You should definitely have 
to say that a specific variable is `__metadata`/enhanced 
`@system`. So I'd have to find a different solution as to how 
DIP1035 attempts to resolve global variables which are 
initialized to unsafe data, e.g.
```d
// global scope
@system:
int* x = cast(int*) 0xDEADBEEF;
```
First of all, I don't remember anyone actually complaining about 
this kind of thing. So it's not really bothering me. But this is 
how I'd solve it with my proposal, if I had to:

- Have the compiler make a subtle distinction between a `@system` 
*variable* and a `@system` *initialization*. This is solely to 
avoid having a separate keyword (e.g. `@systemVar`) for empowered 
`@system` variables as opposed to just ones which are initialized 
unsafely. It's a little messy, but the result would be
```d
@system:
int* x = cast(int*) 0xDEADBEEF; // detected as initialized 
unsafely
@system int* y = 0xDEADBEEF; // specifically marked @system and 
therefore empowered with `__mutable` too

void main() @safe {
     *x = 10; // error: variable `x` was detected to have been 
initialized
              //   unsafely, so its reference cannot be modified 
in safe code
     *y = 10; // error: `@system` variable `y` cannot be modified 
in safe code
}
```
I'm pretty sure that would solve that problem.

--

DIP1035 also suggests that an "aggregate with at least one 
@system field is an unsafe type." I think this might be going too 
far. If you have to be in `@system` code to touch even the safe 
members of the type, I suspect you will lose the opportunity to 
catch a lot of unsafe bugs. I think it should be "any action 
which read or writes a `@system` variable is a `@system` action." 
But I would seek more clarification from the DIP authors on what 
they really meant by making the whole type unsafe.

--

None of this matters, of course. I don't think I can convince 
anybody that my proposal is worth trying, especially when you can 
just as easily adopt both DIP1035 and `__metadata` separately and 
see how things go. I just wanted to amend my previous claim to 
say that at minimum, you should have to mark empowered 
`@system`/`__metadata` specifically and that they shouldn't be 
inferred.

Zach


More information about the Digitalmars-d mailing list