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

Adam D. Ruppe destructionator at gmail.com
Fri Jan 3 14:36:26 UTC 2020

On Friday, 3 January 2020 at 11:31:43 UTC, Walter Bright wrote:
> Oh, if only that were true. (I have decades of experience with 
> this.)

I've had a few times when things got outright corrupted in D and 
those are indeed very difficult to find.

But like my last snarky email said, D is different because we 
have RangeError. It is very rare that things get out of control 
here. Even in cases where we want to bypass range error, it can 
easily be done in isolation meaning the checks still protect you.

This is both good and bad for this dip.

Good: I suspect a majority of D code already qualifies for @safe. 
The pain impact is likely to be small, and with the default set 
correctly, more libraries will work and those benefits can bubble 
up to user code.

Bad: It is a bit of a hassle to deal with breakage when it comes 
up and the benefit is likely to be small, since most code is 
already free of the trouble it aims to solve.

I fall a bit on the "yes" side since I do think the good slightly 
outweighs the bad.

But let's not unfairly trash D as it stands to make this case 
stronger. We're already streets ahead of C++ even without this 
dip so talking about bad experiences and overall statistics from 
C and C++ don't necessarily apply to D.

More information about the Digitalmars-d mailing list