D Language Foundation July 2023 Quarterly Meeting Summary

[Paul Backus]

On Saturday, 29 July 2023 at 14:15:12 UTC, Mike Parker wrote:
> There's also the problem that some of the deprecations are for 
> features that cause code to be unsafe. The issue here is that 
> the compiler is unable to prove that the code is safe. It 
> doesn't mean that the code is unsafe or broken. So he planned 
> to modify that such that you only get compiler guarantees in 
> `@safe` code when you have fixed all the warnings about legacy 
> behavior. That will not break existing, working, debugged code, 
> but if you want the compiler guarantees about safety, you're 
> going to have to turn on `-wo` and fix the warnings it gives 
> you.

I really hope that this plan will be reconsidered. Users of @safe 
have already opted into stricter-than-default checks by putting 
the @safe attribute on their code. Forcing them to pass an 
additional compiler flag to say "no, really, I mean it" and 
having that flag bundle together both safety-related and 
non-safety related warnings will simply discourage D programmers 
from using @safe in the first place (if they haven't been 
already!), and render it near-useless for anyone who does.

I'm honestly shocked that in a few short years, we've gone from 
DIP 1028 and @safe-by-default to cutting safety off at the knees 
in the name of backward compatibility. Is safety no longer a top 
priority for D's leadership?