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

[Steven Schveighoffer]

On 1/3/20 3:59 PM, Guillaume Piolat wrote:
> 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":
>>
>> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md 
>>
>>
>> All review-related feedback on and discussion of the DIP should occur 
>> in this thread. The review period will end at 11:59 PM ET on January 
>> 16, or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP 
>> will be scheduled for another round of Community Review. Otherwise, it 
>> will be queued for the Final Review and Formal Assessment.
>>
>> Anyone intending to post feedback in this thread is expected to be 
>> familiar with the reviewer guidelines:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> *Please stay on topic!*
>>
>> Thanks in advance to all who participate.
> 
> 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

Can we auto-check this? It should be as easy as checking out each 
package and doing dub build with an altered compiler, along with the 
current one. If the current compiler builds but the altered one does 
not, then you have found an issue to be reported/analyzed. Such use 
cases would be instrumental for finding a reason NOT to do this DIP, or 
alternatively, show how little breakage would be.

I tend to think that the breakages will be both minor and few.

> - it doesn't seem like Community input is wanted in any way, it's all 
> "there is no choice"

There is no choice in that D must support safety. But I'm certain that 
if there were a very compelling reason not to make it the default, this 
would not be accepted. This IS the community feedback.

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

It's very much an enabler because people tend to write safe code all the 
time without marking it. For example, I'm sure iopipe (with the 
exception of the calls into c-libraries such as memchr and zlib) can be 
marked safe. But I didn't, because I haven't bothered to worry about it. 
But absolutely it should be @safe.

I'd probably have to adjust a few things, and then it will build. The 
benefit is huge, because then someone doesn't have to choose between 
memory safety and iopipe speed. If the compiler complained about this 
when I was developing it, I'd fix the problems as they happened.

> - benefits are overstated since D has always had a lot less memory 
> corruption than C++ (thanks to slices, GC, bounds-checks, and default 
> initialization!). And C++ has less corruption than C thanks to 
> encapsulation. CVE are often due to C which has the maximum number of 
> corruptions.

The difference will be huge. I don't know if this can be overstated. I'd 
say 99% of code written is ALREADY safe. But we are missing out on the 
benefits of that because we don't bother marking (lazy idiots that we 
are). Then you have an ecosystem that is safe-unfriendly, and it begets 
more code that is safe unfriendly. Once any dependency didn't pay 
attention to safe, you have to deal with it with @trusted at the higher 
levels, and it's turtles all the way down. This is very similar to the 
const problem.

Take for example, mysql-native. Nothing in there is really safe 
friendly, yet. So if I want to use mysql, I have to make MY code 
safe-unfriendly, or just insert trusted escapes for everything, hoping 
that mysql-native is really actually safe (it pretty much is).

One step further, vibe.d now complains all over the place that your 
handlers are not safe, especially for REST routes. If I want to use 
mysql-native and vibe.d, everything either has to be trusted, or I have 
to use some other library.

When the compiler complains about the 1% of your code that isn't 
mechanically checkable as safe, you will spend the 1% of your time to 
fix it, and move on. It will just feel like another syntax error "oh 
yeah, I forgot a semicolon". I don't complain about semicolon 
requirements, I just fix them and move on.

> If one's software is an attack vector, then people that care could use 
> the @safe subset instead of making the life of every beginner worse.

How does this make beginner life worse? Does the beginner start off 
doing pointer math, or using void *? The advantage here is that D 
eschews such things for more safe features, so D code is usually safe 
anyway!

void main()
{
    import std.stdio;
    writeln("Hello, world!");
}

will still work.

-Steve