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