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

[Joseph Rushton Wakeling]

On Tuesday, 14 January 2020 at 05:23:10 UTC, Arine wrote:
> 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.

It's not about what _I'm_ doing.  There are already DIPs and 
experimental features that extend the reach of what @safe can 
verify, allowing validation of memory safety for various GC-free 
(or rather, GC-agnostic) scenarios.

That doesn't impose Rust-style restrictions on anyone who doesn't 
want them -- you can GC away to your heart's content -- but it 
makes it more possible for people who want to work _without_ the 
GC to validate the memory safety of their programs.

And that provides a context where @safe-by-default might start to 
look less intrusive.

BTW, note that Rust, having dropped built-in GC early on in its 
design, is now looking at ways to support it as a developer 
opt-in: https://docs.rs/gc/0.3.3/gc/

So, these things are not either-or.  Whether a developer wants to 
use GC or not (or a hybrid of GC- and non-GC-backed memory 
allocation), there's a common interest in being able to validate 
at compile time that the overall result is memory safe.

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

I'm sorry, but I can't find the example you are referring to.  
Can you provide a link to the post?

As for the rest of your remarks: I understand (and sympathize) 
with the wish for better ways to track down those parts of a 
codebase that need manual validation.  But that problem is the 
same problem whether we have @safe as an opt-in or as the default.

 From what you've written elsewhere, do I understand correctly 
that what you're arguing for is an alternative way of marking 
those pieces of code, and that you believe this would make it 
easier to search out those problematic parts of a codebase?

On that note I disagree with your earlier remark:

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

I agree that @trusted can be abused, but limiting us to just 
@unsafe (à la Rust) seems to me to be unacceptable.

One of the horrible things about Rust is that you can put an 
`unsafe { ... }` block around any single arbitrary line inside a 
function, and the compiler stops complaining -- despite the fact 
that the validity of that unsafe call may be contingent on stuff 
in the other lines of the function.  And yet the function 
signature offers no clue to the user that there might be anything 
risky going on underneath.

@trusted allows us to clearly annotate those function signatures 
such that the user is always clear which functions are in need of 
overall validation.

FWIW I agree with Steven Schveighoffer that it would be useful to 
update the behaviour of @trusted such that the developer must 
mark up the explicitly unsafe lines: 
https://forum.dlang.org/post/qv7t8b$2h2t$1@digitalmars.com

However, I'm not sure that this needs to be coupled with the 
current DIP.  It's a complementary and helpful change to a 
@safe-by-default switchover, but not a _necessary_ one.