-preview=safer for D
Adam D Ruppe
destructionator at gmail.com
Sun Dec 15 14:12:12 UTC 2024
On Sunday, 15 December 2024 at 12:05:46 UTC, matheus wrote:
> I wonder how OpenD are doing since they turned this feature on
> in their branch.
The OpenD impl is different in some key ways:
* it is on by default. things hidden behind compiler switches
might as well not exist; they're unlikely to be used except by
hardcore enthusiasts, which is the same group of people already
writing @safe everywhere.
* it does deprecations instead of errors. It alerts you, but
you're still free to ignore them and carry on - important for
using it with third party dependencies that don't keep up with
the bleeding edge
* the error messages use "non- at system, non- at trusted" instead of
"@safe" since that better indicates what the code actually says
* not all @safe checks are enabled. Ones that are redundant (the
general idea is if you had to go out of your way to write the
code, no point deprecating since the programmer ought to have
already realized they're going off the beaten path) or are
onerous (this was a subjective feeling, but I compiled about a
half million lines of real world D code and where it took a bunch
of time to satisfy the compiler without actually bringing my
attention to any buggy code) are NOT checked by default; you
still opt into them with @safe like before.
* it is possible to tighten the restrictions as time goes on and
"force" - insomuch as a deprecation message is a forcing
mechanism - programmers to get more and more strict. Among
possible (but untaken and unsure if it is even worth taking)
future directions are to enable the scope escape checks / taking
address of local var again, or prohibiting the call of explicitly
@system functions from unannotated functions too.
Details here (and yes, note the date on this is March):
https://dpldocs.info/this-week-in-d/Blog.Posted_2024_03_25.html
There's been a few small changes since this was written, but
safer-by-default has mostly been successful as-is - it found a
few actual bugs in real world code without being impossible to
adopt in practice, so the feature has had a net positive effect
on memory safety - and we've moved on to other things to focus on
in OpenD land including but not limited to full
extern(Objective-C) support (which is in an upstream ldc beta now
too), Webassembly support built into druntime (along with a
work-in-progress bare metal support in druntime itself!), and
more.
More information about the Digitalmars-d
mailing list