On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
----
[...]
First, thank you for taking the time to summarize your position.
I understand
your objection to the proposed amendment much better now than I
did after
only reviewing the discussion thread.
Second, I'd like to present a potential failure mode of DIP 1028
that I think
still remains unaddressed. Consider the following scenario:
Someone has created bindings for a C library and published them on
code.dlang.org. Because they were written prior to DIP 1028, the
author assumed
that @system was the default, and didn't bother to add explicit
annotations to
@system functions. Their code looks like this:
--- clibrary.d
void monkey_around(...); // assumed @system-by-default
---
Months or years later, I decide to write a D program that makes
use of these
bindings. By then, @safe-by-default has been fully implemented. I
add
`clibrary` as a dependency to my Dub project and write the
following code:
--- app.d
import clibrary;
void main() // @safe-by-default
{
/* ... code ... */
monkey_around(...);
/* ... more code ... */
}
---
My program compiles with no errors...and then corrupts memory at
run-time, even
though every line of code I've written is @safe. Oops.
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into existing, correct D code.
Of course, the author of clibrary.d *should* update their code to
add explicit
@system annotations, but how will they know there's a problem if
the compiler
never complains about it? Most likely, by the time they or one of
their users
finally track down the root of the problem, the damage will
already have been
done.
Something ought to be done to prevent this. It doesn't have to be
the exact
proposal from the discussion thread, but doing nothing and
allowing widespread
silent breakage cannot possibly be the best solution.
