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

[Mathias Lang]

On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1028, "Make @safe the Default":
>

On paper, this sounds like a great idea. Make '@safe' the default 
so people have to opt out of memory safety rather than opt-in. 
However, we have extensive experience with those changes (and how 
they are handled), and I am not, as it stands, in favor of it.

First, because '@safe', and attributes by extension, is currently 
not a practical tool, and even not usable in some cases. It is 
currently painful to mix differently-attributed code if you are 
not going full template (e.g. classes, delegates). I've worked 
for two companies using D, and none of them used @safe, and were 
more on the low-level side of things.
In fact, @safe wouldn't even have prevented most of the bug we 
had, as they were fibers stack overflow (I'm sure any fiber user 
know what I'm talking about).

Second because those kind of changes have historically been badly 
handled, as the impact is not fully assessed. For such a large 
and impactful change, I would expect the proposer of the DIP to 
assess the impact of this change on a few projects, in order to 
provide a data point. Either go with major D projects, and/or 
pull a sample for the dub registry, to gauge the hassle, 
performance and readability degradation it can bring.
Yet DMD is not @safe. Neither is druntime. DUB, Vibe.d ? Neither. 
And I've seen countless places where '@safe' is either forced on 
the user (by forcing the user to provide '@safe' routines), or 
just bypassed by means of '@trusted'. Just take a look at Vibe.d.
Side note, using this flag to compile Phobos would most likely 
result in link failures, like it did with DIP1000.

Third, we start to have a few DIPs piling up in the -preview 
section. DIP25, DIP1000, DIP1008. Some libraries use it, some 
don't, and adding more features there will only balkanize the 
language more. Let's not repeat the `std.experimental` experience 
with the compiler, and actually finish what we started.

TL;DR: Disruptive change that requires every D user to put some 
work to support it (possibly many months worth of work), yet no 
evidence that a single large-scale project have been experimented 
with while writing this DIP.