Rebooting the __metada/__mutable discussion

Bruce Carneal bcarneal at gmail.com
Sun Apr 10 05:41:36 UTC 2022


On Sunday, 10 April 2022 at 04:12:08 UTC, Zach Tollen wrote:
> On Sunday, 10 April 2022 at 03:37:03 UTC, Bruce Carneal wrote:
>> [...]
>
> Well thanks for your interest, at any rate. And your honesty.
>
> Out of curiosity, do you have an opinion of 
> [DIP1035](https://github.com/dlang/DIPs/blob/72f41cffe68ff1f2d4c033b5728ef37e282461dd/DIPs/DIP1035.md)? At least intuitively, I feel like the essence of it should run: "Some variables are dangerous, but the compiler can't figure that out. Therefore we allow those variables to be marked `@system` so they are treated as unsafe."

I view 1035 as a mechanism to extend the reach of @safe, to 
reduce the load on conscientious code reviewers.

>
> But there are other parts of DIP1035 (initializing globals to 
> unsafe values, and also, an entire aggregate is unsafe if a 
> single member is unsafe) which seem to be about *inferring* 
> certain things to be unsafe as opposed to helping the compiler 
> to *determine* what is unsafe. My interest in merging the two 
> DIPS came almost entirely from seeing the value in the "help 
> the compiler learn what is unsafe" side, and I thought the 
> "inferring things unsafe" side could be handled separately. 
> (The helping-the-compiler side is eloquently illustrated in the 
> one of the DIP's linked [videos](https://youtu.be/O3TO52rXLug) 
> by Steven Schveighoffer. That's where I got my understanding of 
> what I thought the essence of DIP1035 *should* be about. Of 
> course, that's no reason to arbitrarily merge the two features, 
> `@system` and `__metadata`. But it might make it easier to 
> explain why I thought it was possible.)

Thanks for the explanation.  I think Steven is a good one to 
listen to.  He talks sense habitually.

If you're available do join us and others at the next beerconf to 
talk about this and other topics.  Paul, another of the good ones 
and DIP 1035 co-author, sometimes joins in as well.



More information about the Digitalmars-d mailing list