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

[Joseph Rushton Wakeling]

On Monday, 13 January 2020 at 17:13:36 UTC, Arine wrote:
> 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.

Yes, indeed.  That's kind of the point -- Rust has established a 
set of viable techniques for proving memory safety in a systems 
programming context.  That in turn establishes that there is lot 
of scope for D to improve its memory-safety guarantees (in 
particular, being able to prove memory safety criteria in GC-free 
code).

D has been learning and adapting from that -- and can continue to 
do so.  But in terms of considering the basic viability of this 
DIP, the important point of consideration is whether it is 
desirable to have provable memory safety by default in a systems 
programming language.  Rust gives us a clear example that it can 
be both desirable and achievable.  The move to ever-more-parallel 
development gives us the extra motivation for why this will 
matter more and more in future.

All the other stuff comes down to implementation details.  The 
question is which of those implementation details matter when it 
comes to making @safe-by-default viable in practice, and whether 
that is achievable with minimal transition problems.

Note that all this is saying is that it is valid to make the 
proposal.  It doesn't say that the proposal should be accepted 
(either on principled or on practical grounds).  You may notice 
plenty of practical critique in the feedback I offered.

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

Genuine question, as I'm not a Java dev: does Java genuinely 
provide _provable_ memory safety?  Or is it just that in practice 
things will be memory safe because of the GC, and it doesn't 
allow you access to features that escape that safety blanket?

> It's not just keyword choices. It's fundamentally how 
> discover-able @unsafe code is while reading @safe code.

Isn't that the same as it's ever been -- search for @trusted 
blocks?  I don't see how that would change.