@safe by default

Paul Backus snarwin at gmail.com
Fri May 31 13:06:16 UTC 2024


On Thursday, 30 May 2024 at 18:35:36 UTC, Atila Neves wrote:
> https://github.com/atilaneves/DIPs/blob/safe-by-default/safe-by-default.md
>
> Destroy!

I agree completely that "having [@safe] be opt-in makes it hard 
to use in practice" and that "defaults matter". However, I think 
that implementing [Universal Function Attribute Inference][1] 
would be a better way to address the shortcomings of the current 
defaults.

In ["Thoughts on Backward Compatibility"][2], I tried to figure 
out why some breaking changes succeed and others fail. The 
conclusion I came to was that breaking changes are most 
successful when:

1. Migration is easy, or
2. The change serves a goal that has strong buy-in from users

While there is a vocal minority in the D community who strongly 
support @safe (a group in which I include myself), **I do not 
believe that @safe has strong buy-in from D programmers as a 
whole.** In other words, this proposal cannot satisfy condition 
(2). It follows that, if we would like it to succeed, it *must* 
satisfy condition (1).

Sadly, I do not think migration to `-preview=safedefault` will be 
particularly easy. By the DIP's own admission, it "will likely 
break a lot of code". Even if editions allow us to mix 
pre-migration and post-migration code in the same project, the 
burden of migrating to `-preview=safedefault` will likely hurt 
the adoption of new editions, and cause projects that would 
otherwise upgrade to get "stuck" in the @system-by-default 
edition.

(It is also conceivable that new projects started by D 
programmers who don't care about @safe will choose the old, 
@system-by-default edition specifically to avoid the hassle of 
adding explicit @system attributes to their code.)

Universal inference avoids these problems. In most cases, it 
requires zero manual intervention to migrate existing code (that 
is, it Just Works™). The only major obstacle it faces is build 
performance when using separate compilation, and this obstacle 
can be overcome with toolchain improvements.

Inference also solves the wrong-default problem for @nogc, 
nothrow, and pure, in addition to @safe, without the need for any 
additional -preview switches or migrations. Asking users to 
migrate from @system-by-default to @safe-by-default may be 
doable, but can we really ask them to do the same thing *three 
more times* for the other attributes?

[1]: 
https://forum.dlang.org/thread/pfawiqhppkearetcrkno@forum.dlang.org
[2]: 
https://forum.dlang.org/post/axvuuknmtxpmuirbbgax@forum.dlang.org


More information about the dip.ideas mailing list