Direction for @safe/-dip1000

[ag0aep6g]

On 13.02.22 12:15, Florian Weimer wrote:
> I've tried to figure out where this is heading. Is the eventual goal 
> (irrespective of mechanism) that sticking `@safe` onto the `main` 
> function will ensure memory safety for the whole program?

Roughly, that's what @safe is supposed to be, yes. But it's not quite as 
simple because `main` isn't the only possible entry point, and because 
@trusted exists.

> What about data races in updates of multi-word variables?

As far as I know, this is D's current approach:

All shared data must be marked with `shared`. @safe code cannot access 
`shared` data (only enforced with `-preview=nosharedaccess`). If you 
want to mess with `shared` data, you need to write @system/@trusted code 
and ensure thread safety yourself.

Since you mentioned it in the topic, note that DIP 1000 doesn't make 
@safe safer. It allows some formerly @system code to become @safe. If 
you write that kind of code, DIP 1000 is nice to have. If you don't, DIP 
1000 doesn't affect you.