DIP1028 - Rationale for accepting as is

Paul Backus snarwin at gmail.com
Fri May 22 03:36:03 UTC 2020


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.


More information about the Digitalmars-d-announce mailing list