Both safe and wrong?

[Olivier FAURE]

On Friday, 8 February 2019 at 09:40:09 UTC, ag0aep6g wrote:
> Right now, to ensure that a program is actually safe, one has 
> to:
>
> 1) Check `main`. I.e., mark it @safe, or verify it manually.
> 2) Manually verify all @trusted code.
> 3) Check all static constructors.
> 4) Check all statically initialized variables that are not in a 
> function: module-level variables, class/struct fields, anything 
> else?
> 5) Account for bugs in @safe and stuff that I'm forgetting here.
>
> Ideally, the list would be as short as possible. So if we can 
> eliminate #4, that would be a good thing, in my opinion.

Right.

Like I said earlier, one way to eliminate #4 would be to say 
"variables that aren't marked as @safe can't be called from safe 
code". The problem with that is that it would break tons of 
existing code.

Alternate solutions:
- Make global variables @safe by default.
- Deduce @safety by default from a global variable's 
initialization expression.

Both of these solutions would involve very little code breakage, 
but would break with existing D semantics, which is yet another 
wart you have to explain to beginners.

(alternate alternate solution: make an "everything is @safe by 
default" DIP, and use a -dipXXXX flag for the transition for a 
few years)