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

[mipri]

On Friday, 3 January 2020 at 20:59:45 UTC, Guillaume Piolat wrote:
> I'm still against:
> - it break everything for everyone, so we'll lose working 
> packages on code.dlang.org who happen to have no maintainer but 
> have worked for years

This is technical problem with solutions like this one:
https://forum.dlang.org/post/vcubtfjpwzbsleayexwy@forum.dlang.org

> - ...but doing it just move the default. It's not an enabler 
> for "safe reference counting" or things like that, since it's 
> just a default.
> - benefits are overstated

Defaults are enormously important though. Putting aside the
rate of bugs, when you *do* have one in front of you, defaults
matter more than anything else in terms of how readily you can
find the problem. When @safe is the default, if you have a
memory error, you can grep your code base for the nonsafe bits
and catalogue them and start there.

Another result: people will try something, get an error, and
then ask: "should I mark this @trusted so I can do what I
wanted, or use a safer construct and not have to do that?" Just
the question is helpful, but it's also likely that there will
be a greater incidence of people going with the safer construct
and then avoiding problems altogether.

Another result: instead of the status quo of "mark something
@safe -> get explosion of errors because so much code is
@system unnecessarily -> realize what a chore it would be to
make @trusted interfaces to this code -> remove @safe", you're
more likely to not have problems at all because the code you
call is already @safe because that's the default.

Another result: just by having the compiler option and a
deprecation cycle started, people will start actually reporting
problems with @safe, like they are in this thread right now,
instead of running into those problems and grumbling "eh I
guess this is half baked, I'll just not use it".