-preview=safer for D

[Jonathan M Davis]

On Saturday, December 14, 2024 1:46:35 AM MST Walter Bright via Digitalmars-d wrote:
> Now that this has been merged into master, what are your reactions?
>

Honestly, the more I think about it, the less I see the point in it, but I
also don't see it as a problem so long as it never becomes the default.

If I want a function to be @safe, I'll mark it with @safe, and I'll get all
of the appropriate checks. The fact that I didn't mark a function with @safe
means that I either want it to be @system and was relying on the current
default - or more likely that I didn't care about @safety at all with that
piece of code (which often happens with stuff like scripts or other small
programs).

I assume that the point behind the flag is to provide a tool to track down
places where there would be issues when @safe becomes the default so that
they can be fixed now, but if I actually want to do that, I can just start
putting @safe on my functions, and there's no need for a compiler flag.

So, from what I can see, the only real use case for -preview=safer is if I
want to check a bunch of code for @safe without taking the time to actually
mark it with @safe under the assumption that when @safe becomes the default,
those explicit attributes will be unnecessary. And maybe that's worth having
the flag for (and you already implemented it regardless), but in my case, if
I actually care about a particular piece of code being checked for @safe,
I'm just going to take the time to mark it with @safe, and then I also get
the benefit of being able to call that function from @safe code, which the
flag doesn't help with.

So, I don't necessarily see any problem with the flag, but I also don't see
much benefit in using it.

On the other hand, if your plan is to ever make -preview=safer the default,
then I think that that's a serious problem, because it's forcing almost all
of the @safe checks without actually making @safe the default. So, all of
the code that fails the flag will break, and you'll _still_ have to go and
mark all of the functions with @safe if you want to actually call them from
@safe code. So, it's forcing almost all of the checks on everything that
isn't explicitly @system (just missing the one about calling @system
functions) without actually providing the full benefits. From what I can
see, simply turning on @safe by default would make more sense than turning
on -preview=safer as the default.

So, I have no problem with the flag as a linting tool to prepare for @safe
by default, but I very much hope that it's not your intention to ever make
the flag the default. And I would expect that in most cases, anyone who
actually cares about @safe enough to use the flag would be using @safe
explicitly anyway, but I can certaintly believe that some folks will want to
use the flag to check for potential issues with @safe by default without
actually taking the time to mark anything with @safe to then get the full
benefits of @safe now.

- Jonathan M Davis