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