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

[Mathias Lang]

On Friday, 3 January 2020 at 11:06:32 UTC, Walter Bright wrote:
>
> Modules can be labeled as @system by beginning them with:
>
>    @system:
>

As mentioned countless times already, this has a widely different 
effect.

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

https://issues.dlang.org/show_bug.cgi?id=17953
This affects object.Throwable.toString. I'm not asking for that 
specific syntax, but we do need a way to say "delegate attributes 
in, delegate attributes out".

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

Except that I do not control all the code I write. Some libraries 
will use `@safe` everywhere, some won't. And mixing them becomes 
a nightmare. For example, I'd be very happy to live without 
`@safe`, but I use Vibe.d, which forces `@safe` on me because 
some people wanted to be able to use `@safe` in the first place. 
This is the kind of ecosystem split people keep talking about.

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

In terms of cost/benefit ratio, it does not cross the mark for me.
I also recently spent 3 days debugging a memory corruption issue, 
happening because of a stack overflow, something `@safe` can't 
prevent. So here's another anecdotal evidence for your anecdotal 
evidence.

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

If I wanted to be using Rust, I would be using Rust.


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

And I invite you to try it already (you don't need it to be 
merged to start fixing `@safe`ty issues) to see the effect. Note 
that DMD is not a library and has almost no dependency, which 
makes fixing issues much simpler.

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

Because `scope` is ignored for mangling. `@safe` cannot be 
ignored, so the same solution cannot be used.

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

I don't disagree with improving the language, I disagree with the 
way of doing it. If `@safe` was hassle-free we wouldn't be having 
this conversation, but it's not, and making it the default just 
switch the hassle to someone else.


> > actually finish what we started.
>
> All issues need to go into bugzilla. Issues not in bugzilla do 
> not get fixed.

There's a trove of issues in bugzilla to pick from. But put in 
simpler terms: Where is `@safe` reference counting ?


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

And then, nobody will try it unless druntime / Phobos is compiled 
with it. But then we're back to the point where it's not really 
opt-in because of link failures. I'll add more of that on the PR 
itself.