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