-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