@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