DIP 1028---Make @safe the Default---Community Review Round 1
arine123445128843 at gmail.com
Mon Jan 13 17:13:36 UTC 2020
On Monday, 13 January 2020 at 15:57:38 UTC, Joseph Rushton
> 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.
More information about the Digitalmars-d