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

[Arine]

On Monday, 13 January 2020 at 17:34:48 UTC, Joseph Rushton 
Wakeling wrote:
> 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).

That's the thing, D has a GC. If you are now trying to push 
Rust-like features into @safe to allow @safe non-gc memory, you 
are going to be adding restricting code that would otherwise not 
have to be to be @safe with a GC. So the language becomes more 
restrictive like Rust, all while losing the benefit of having a 
GC and not needing to worry about those restrictions. The DIP 
that tried to disable dynamic array resizing is proof of that.

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

Depends what you mean by provable. If you mean using potentially 
unsafe features and the compiler being able to prove they are 
being used safely, no I don't think any compiler does that. If 
you mean it's provable to be safe because it doesn't allow unsafe 
features like basically what D does, then yes. It'd be more safe 
than D in that regard as it simply doesn't allow pointers. If you 
also take into consideration, in it's current state, D isn't 
provable to be safe as it has features that a provably *unsafe*. 
At least one person here even thought you couldn't use the 
feature in @safe code (see: void initializers).

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

If your in a @safe function trying to figure out where unsafe 
calls are, how would you search for @trusted? The function you 
are searching for could be in one of the thousands of different 
files. Are you going to go look at each and every one? There's an 
example a few pages back that illustrates this.