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

[Arine]

On Monday, 13 January 2020 at 15:57:38 UTC, Joseph Rushton 
Wakeling wrote:
> Clearly yes: @safe-by-default fits within an observable trend 
> of languages getting more and more concerned with provable 
> memory safety, and with a related trend of requiring the user 
> to write provably safe code.  Rust in particular has 
> significantly raised the bar in this space, and proven that 
> such constraints are often welcomed by developers.

Rust doesn't just provide safety. It also provides a lot more 
other guarantees than just safety. It is low level and achieves 
memory safety *without* a GC. It provides guarantees for multi 
threading, that reduces data races and other difficult to 
diagnose problems. This is a world where single thread 
performance isn't getting significantly faster. But we are now 
getting CPUs with 64 cores and 128 threads.

You can't just look at one aspect for Rust, without looking at 
every aspect. Java provides memory safety, but there's a reason 
why people using Rust don't use Java.


> As a separate issue, it's probably a good idea to take 
> discussion of keyword choices off the table for the purposes of 
> this DIP.  @safe, @trusted and @system have well-defined 
> meanings which are entirely compatible with the transition to 
> @safe-by-default.  We should keep our focus on the stuff that 
> needs to change, not the stuff that doesn't.

It's not just keyword choices. It's fundamentally how 
discover-able @unsafe code is while reading @safe code. This DIP 
is a big breaking change that is going to break basically all 
code out there. All documentation, all discussions, all example 
code, ~everything~. This is probably the only time to discuss 
something like this. It wouldn't make sense to accept this DIP, 
then have another DIP that causes a similar amount of breakage 
regarding a similar aspect of the language.

> In short: since nothing stops anyone who cares from having a 
> `@safe` codebase right now through the existing opt-in 
> features, show us in detail how the pain of transitioning to 
> opt-out is really worth it ;-)

I agree with this. People that want to write @safe code write 
@safe code. Those that don't want to, don't. Making safe by 
default won't make people write @safe code that is actually safe, 
it'll just make them misuse @trusted more.