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

[Kagamin]

On Wednesday, 25 March 2020 at 22:40:10 UTC, H. S. Teoh wrote:
> 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.

Even to get those minor benefits your code should be annotated 
with `scope`, `return` and whatnot. And even then dip1000 is not 
the default yet, so even those minor benefits are out. If people 
are lazy to add 6 characters `@safe:` why do you think people 
aren't lazy enough to keep their codebase dip1000 compliant?