DIP 1028---Make @safe the Default---Community Review Round 1

Atila Neves atila.neves at gmail.com
Sat Jan 4 10:42:57 UTC 2020


On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:

[snip]

> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

I get the impression that most of the negative feedback here 
falls into the following categories:

1) This will break too much code
2) Crappy code is ok, don't burden users to make their code @safe
3) It's too much effort to convert existing code to @safe

Having basically *only* written @safe code for years now 
(although sometimes misusing @trusted), here are my opinions on 
the categories I came up with:

1)
As with every other recent DIP, the change will be gated with 
`-preview` so initially it will be opt-in. No breakages will 
happen overnight.

Also as with every other recent DIP, after that initial period it 
will become opt-out with `-revert`. At most, and only sometime in 
the future, breakages can be easily avoided by adding one flag to 
the compiler invocation command. I wish it weren't true, but I 
suspect that this particular revert flag will last for quite a 
while.


2) and 3)
Most D code is @safe. Nearly all of it is. Unless you're taking 
addresses of locals (which can be made @safe by using DIP1000 and 
scope), doing pointer arithmetic, or slicing pointers, nearly all 
instances of @system code left will be casts. I would be very 
surprised if many changes have to be made, *especially* if the 
default becomes @safe since most of the problems I face are in 
dependencies.

This is why changing the default is important: most code is @safe 
anyway but we're not getting the benefits because it's more 
effort to annotate than not, so most people don't bother.

"But we're already safer than C++" is analogous to "but we 
already compile faster than C++". They're both low bars to set, 
and the compiler can never be "too fast". Eliminating more bugs 
at compile-time is one of our goals. This DIP helps us get closer 
to the ideal.


More information about the Digitalmars-d mailing list