Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[H. S. Teoh]

On Wed, Mar 25, 2020 at 09:58:40PM +0000, Jonathan Marler via Digitalmars-d wrote:
[...]
> That being said, in practice I'm not sure how much benefit @safe
> actually provides. In theory it sounds nice.  It could help audit
> code, but for me, I audit all my code the same whether or not it's
> safe.  So for me the whole feature seems kinda pointless. Maybe this
> is different for others?  Does anyone have any real life
> examples/experience where @safe has helped?  Has the benefit warranted
> the cost to manage these tags throughout your code? Do we have any
> projects that are already using this behavior by putting "@safe:" at
> the top of every file?  Does anyone have any pointers to projects that
> have done this?  Have they seen any benefits from doing so?

Some of the latest new features like DIP1000 are in full force only
inside @safe code.  I've run into a couple of escaping reference bugs
that were not caught because I didn't tag my code @safe, but once I
added @safe I immediately got a compiler error pinpointing the code that
leaked a scoped reference.

I wouldn't say this is a big impact, but it did catch a couple of bugs
that would've been a pain to track down.  From this perspective, it
makes sense to make @safe the default: most users would not bother with
the pain of manually tagging everything @safe just to get a few minor
benefits.  But having it by default means everyone reaps the benefits,
and where you need an escape to do something seemingly dangerous, you
can explicitly use @system or @trusted to temporarily suspend the
compiler's checks for specific bits of code.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds