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

[Walter Bright]

On 1/2/2020 10:31 PM, Mathias Lang wrote:
> 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.

Modules can be labeled as @system by beginning them with:

    @system:


> First, because '@safe', and attributes by extension, is currently not a 
> practical tool, and even not usable in some cases.

Issues not in bugzilla do not get fixed. Please add issues that make it not 
practical or usable to bugzilla and mark them with the `safe` keyword.


> 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.

It is true that using @safe successfully will often entail some level of 
refactoring to separate the safe code from unsafe code. It is perfectly fine if 
you choose to not use @safe.


> In fact, @safe wouldn't even have prevented most of the bug we had,

Most is not all, and the bugs it does uncover tend to be the ugly ones. I 
recently spent 3 days trying to track down a memory corruption bug in DMD. These 
are not happy hours for me. Detecting problems at compile time is infinitely 
cheaper.

It's also the future. It's clear where languages are going. Unsafe languages are 
going on the ash heap of history. We can either get in front of this sea change, 
or get run over by it.


> 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.

The simplest way to be compatible with the switch is to simply label things that 
don't compile as @system. Or just put @system: at the beginning.

As for DMD, I intend to take advantage of this feature as soon as it is 
accepted. Keep in mind that DMD was originally a "C with Classes" program, with 
no notion of @safe (or const, pure, nothrow, or nogc).


> Side note, using this flag to compile Phobos would most likely result in link 
> failures, like it did with DIP1000.

We fixed the link failures 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.

All programming languages improve or die.


 > actually finish what we started.

All issues need to go into bugzilla. Issues not in bugzilla do not get fixed.


> 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.

Nobody will try it, either, unless and until it is actually put into the compiler.