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

[Arine]

On Wednesday, 8 January 2020 at 02:48:19 UTC, Walter Bright wrote:
> On 1/6/2020 3:59 PM, Manu wrote:
>> Well all feedback I've received is that it fails at the rule 
>> of least
>> surprise. Definitely not intuitive what it means.
>
> I'm frankly surprised at this. Yours is literally the first 
> complaint about using `system` in 10 years that has come to my 
> ears.
>
> Also, a safe/unsafe dichotomy can make sense. But a 
> safe/trusted/unsafe makes less sense, like a 3 state boolean.

@trusted doesn't really make sense. It is pretty much @system 
that @safe can call. It's actually kind of bad as how easily it 
can be misused. @trusted: comes to mind. You can have @trusted 
destructors. So when you are reading @safe code you can't easily 
tell where potentially @unsafe code is located. As the @trusted 
is applied to the function, not at the call site (like Rust/C#).

If we are going to make @safe the default we don't really need 
@safe keyword, or @system or @trusted. It's make sense to get rid 
of all 3 of them and just add @unsafe. If you are going to do it, 
might as well do it right the first time.


@safe void potentialProblem() {
     A a;

     where();
     is();
     the();
     potential();
     problem(here ? maybe() : maybeNot());
}


// safe by default //
void potentialProblem() {
     A a;

     where();
     is();
     unsafe {
         the(); // easily identifiable
     }
     potential();
     problem(here ? maybe() : maybeNot());
}


>> I think it may be possible to see and consider the situation
>> differently when looking from a safe-by-default perspective; 
>> today
>> where 'system' is default, you wouldn't want to advertise the 
>> language
>> as "unsafe by default"... but if safe is default, than 
>> 'unsafe' feels
>> a lot more reasonable for the exceptions. I reckon the change 
>> in
>> default may change your judgement that you describe above.
>
> `static` in C makes no particular sense, but people are so used 
> to it that they imagine it makes perfect sense :-)
>
> Nobody expects to be able to implement a storage allocator in 
> code that is provably correct. Nobody expects the 
> implementation of atomic shared operations to to be provably. 
> People have historically called such underpinnings "system" 
> code (long before there was a notion of "unsafe"), where the 
> dirty but necessary work happens. Steamships had white-glove 
> service to the passengers, and the greasy dirty work went on in 
> the "system" under the decks to support it all.
>
> Whether "system" is intuitive or not is how you frame it. It's 
> a perfect moniker. It is not "unsafe", it just means the 
> compiler cannot prove it safe.

If you can't prove it is safe, logic dictates it should then be 
identified as unsafe.