Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[Steven Schveighoffer]

On 3/26/20 10:24 AM, Adam D. Ruppe wrote:
> On Thursday, 26 March 2020 at 14:12:24 UTC, Steven Schveighoffer wrote:
>> I still think this is the appropriate path. We cannot continue to 
>> ignore memory safety as a secondary concern just because C code is 
>> by-default unsafe. Memory unsafe HAS to be opt-in for any new modern 
>> language to succeed.
> 
> What frustrates me about these discussions is the facts that slices 
> always check bounds by default. The GC prevents use-after-free bugs by 
> default.

And so any code that uses the defaults will be @safe and continue to 
compile.

> C doesn't do those. So assuming C's problems apply to D is fallacious. 
> Rust's complication is because they wanted to avoid the runtime checks. 
> But D's runtime checks are also a valid solution.

Unsafe D code can do exactly the same thing that C code does (use 
pointers and malloc). The runtime checks are gone at that point. How do 
you distinguish code like that from the good D code?

> I suspect 95+% of C's problems already are extremely rare in D, yet the 
> @safe advocates never seem to consider this at all.

I consider that BECAUSE of these mitigating factors you listed, most D 
code is already @safe, just not marked that way. Most code that is 
written will currently "just work".

Unless it doesn't. We are going to have a hard time finding that code or 
those migration pains without trying it. And it's hard to judge that 
this will be such a huge burden that we need to reconsider this path. 
this is why it should be a trial switch, and people should be encouraged 
to use the switch and report the pains that come from it. We can 
potentially make things pretty seamless of a transition, or even adjust 
our thinking to make things more palatable.

I've recently migrated 2 significant projects into fully-safe code. One 
is diet-ng, which was a couple hours of work. Mostly just consisted of 
slapping @safe: at the top of modules that had non-templates. This is 
because most of the code was ALREADY safe. The one major difficulty? 
Object.opCmp is not safe, even though the implementation in the classes 
was safe. So I have this awesome shim: 
https://github.com/rejectedsoftware/diet-ng/blob/e2e947f24faaa71a4bab9dd8bda6f93375c67755/source/diet/parser.d#L31-L36

The other project was mysql-native. I'm still not finished there, but 
the largest problem is/was Variant. Because of that, I had to create two 
almost identical APIs and split them into safe/unsafe packages (where 
eventually the unsafe packages will be deprecated and removed). Thanks 
to the awesome taggedalgebraic package, and Sönke has been really 
helpful including features to make it easier to do @safe code, we should 
be able to have a drop-in replacement for Variant that is @safe, and 
your code should (almost) just work. You can read about it here (not 
released yet): 
https://github.com/schveiguy/mysql-native/blob/safeupdate/SAFE_MIGRATION.md

My point is, putting in the effort to migrate to @safe is the best way 
to determine where the sticking points are (and there are definitely 
sticking points). Hand-wavy statistics aren't persuasive.

-Steve