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

[Jonathan M Davis]

On Wednesday, March 25, 2020 10:35:23 PM MDT Jonathan Marler via 
Digitalmars-d wrote:
> On Thursday, 26 March 2020 at 02:58:26 UTC, Walter Bright wrote:
> > On 3/25/2020 10:53 AM, Jonathan Marler wrote:
> >> I'm on the fence as to whether this is a good idea.  However,
> >> with all the D code I've written that would break from this
> >> I'd prefer not to do this;
> >
> > Are you sure there'd be that much that breaks? If much does
> > break, I'd suggest re-evaluating the coding techniques you use.
>
> I'm constantly re-evaluating and improving my coding techniques.
> Something I love doing actually.  I'm not sure how this feature
> breaking code is related to poor coding techniques though?  The
> point is that to fix code after this feature comes in, I'll need
> to go through thousands of source files and tag code
> appropriately.  What does this have to do with the quality of the
> code itself?

Making it so that all code must be either verified by the compiler to be
@safe or be marked by the programmer to be @trusted or @system means that
all code which could contain memory safety issues will be segregated by
@trusted or system, whereas right now, you can have large swathes of code
which is not marked with anything and is unchecked. If the programmer is not
using the compiler to verify @safety and is not verifying @system sections
of code and marking it as @trusted, then there are no compiler guarantees
about memory safety in that code. Sure, the programmer may have done a good
enough job that there are no memory safety bugs in the code (and that's far
more likely with D code than C/C++ code), but by making @safe the default,
it makes it so that none of that will fall through the cracks unless the
programmer explicitly tells the compiler to not check.

In general, it should result in either far more code being checked for
memory safety by the compiler or programmers just telling the compiler to
shut up by using some combination of @trusted and @system. So, in the cases
where the programmer allows the compiler to check, there is a real
possibility that memory saftey bugs will be found (thus presumably resulting
in those bugs being fixed), and in the cases where the programmer does not
allow the compiler to check, it's much easier for other programmers to see
that that's what's happening (e.g. simply grepping for @system and @trusted
will show wherever it happens when templates are not involved, which is not
currently the case).

It's certainly possible that you will find very few bugs in your code as a
result of this change, but I think that it should be pretty clear that code
in general will benefit, and you could be surprised by what you find in your
own code.

The only real downsides to this change that I'm aware of are

1. You could have to add a bunch of annotations to existing code, which
could be very annoying (which is what appears to be your main problem with
the DIP).

2. It will make it a bit more annoying to throw together small programs,
because you'll have to either actually make your code @safe or slap @system
on it.

However, in both cases, if you don't care about @safety, you can just slap
@system at the top of all of your modules, much as that isn't great
practice. So, it might be briefly annoying, but it shouldn't be a big deal
long term, and having @safe be the default should result in far more D code
in general being verified for memory safety, which will result in fewer bugs
in D code in general.

- Jonathan M Davis