Both safe and wrong?

[XavierAP]

On Friday, 8 February 2019 at 20:06:02 UTC, Olivier FAURE wrote:
>
> (alternate alternate solution: make an "everything is @safe by 
> default" DIP, and use a -dipXXXX flag for the transition for a 
> few years)

I don't think this would be well received by the betterC/C++ 
crowd. And as important as @safe is for some applications, the 
decision to make it optional and not default was taken long ago, 
and has huge implications. Fixing backwards compatibility for 
this related but separate issue is hardly a warrant for such a 
huge change.

It looks to me too that variables need now to be flagged with the 
attribute, because the alternative is for every one of the @safe 
functions that use any given global variable, to check again on 
their own that there isn’t anything unsafe in its initialization 
code. And then again, you are pushing the compile error that 
belongs on the dependency (global initialization) to the client 
(@safe function)

A possible solution in my opinion is:

- From then on, globals will be flagged @safe, @system or 
@trusted just like functions.

- But under the hood, globals in binaries (already compiled,  so 
currently always without any attribute) are accepted by @safe 
code (as if they were @trusted) – BUT generate a compile warning.

- When compiling new code, globals in this code are subject to 
new restrictions; so they are flagged @safe, @trusted or @system 
explicitly; and if their initialization is unsafe and they’re 
flagged as @safe, they generate a compile error; without need for 
any other compilation unit that uses this variable to check on 
its own.

This way there is no code break. Other than new warnings, which 
are good because they expose a newly discovered vulnerability; or 
re-compiling unsafe global initializations, which should be 
fixed, or may be flagged @trusted, individually or however.