DIP 1028--Make @safe the Default--Formal Assessment

[Arine]

On Thursday, 21 May 2020 at 20:46:09 UTC, Walter Bright wrote:
> On 5/21/2020 9:14 AM, Seb wrote:
>> Why we can't we have a technical board where the community can 
>> vote in experts and potentially companies could even buy a 
>> seat for $$$ which would mean a lot more for them than the 
>> current very vague sponsorship options.
>> I'm aware that Walter doesn't like the idea of giving up 
>> ownership, but it makes all the other people question why they 
>> should still bother with this process and not simply fork and 
>> move to an open, transparent development...
>
> I expected flak from this decision. I'm prepared to take the 
> flak because this is the right decision. I did not make it 
> lightly.

That's interesting that you are saying it is the "right" 
decision. Let's analyze that for a second:

What this boils down to is

     Simplicity Vs. Memory Safety

Is the **correct** code actually simpler? A beginner that doesn't 
have the knowledge of D's safety system will ultimately create C 
bindings that are implicitly @safe without realizing the 
consequences of their actions.

This change introduces a risk to memory safety, extern(C) 
declarations that were @system will now be flipped to @safe. No, 
putting @system: at the top isn't a solution, extern(C) functions 
aren't all nicely put in their own modules. Druntime and Phobos 
both have extern(C) declarations throughout their source; I 
guarantee you missed them with your PR's trying to illustrate how 
simple it is. As others will most definitely miss them as well.

Reasons for Memory Safety:
- Less error prone and simpler for beginners, the default is what 
the *correct* behavior should be. They organically discover @safe 
writing C bindings.
- Less error prone for advanced users, won't accidentally call a 
C function that isn't explicitly verified as being @trusted.
- Switch to @safe by default won't introduce potential security 
bugs from extern(C) functions not being annotated @system in the 
switch.
- Proven implementation by other safe languages (Rust).

Reasons for Simplicity:
- simpler logic for the compiler
- simpler rules for the user that default to *incorrect* code
- Fear of the unknown, unforeseen complexity
- trust Walter


This is where the divide is, from my perspective. There's this 
fear of the unknown, that making it slightly more complicated 
will introduce these unforeseen complications that will far 
outweigh any benefit that is added from it.

I don't see what that can be. There are other languages that have 
safe by default, and then have C declarations be unsafe by 
default. They don't have any of these devastation complications 
you seem to think that there will be.

This is what doesn't sit right with me. If you could give an 
example of a complication that could occur, then I think you 
could get more people onboard. But it would have to be 
justifiable against the increased security risk of having 
extern(C) declarations be @safe by default. For a DIP that is 
trying to increase safety, it is a bit ironic that it will also 
be reducing safety at the same time.

Otherwise right now, as it stands, this basically boils down to 
Logic Vs. Fear.

> Please keep in mind that I've made other unpopular decisions 
> that have proven their worth over time. I hope you'll reserve 
> judgement until we all see how this change plays out.
>
> If it does turn out badly, it's on me and I'll take my lumps.

You've also done the opposite, you can't justify it with such a 
statement unless you've never made a mistake. This whole process 
is suppose to avoid exactly this; a single person taking a gamble.