On Monday, 25 May 2020 at 17:09:50 UTC, Clarice wrote:
On Monday, 25 May 2020 at 16:47:50 UTC, Paul Backus wrote:
the compiler must warn D programmers that their declarations
need to be reviewed for compatibility with @safe-by-default.
Whether they were reviewed before that or not makes no
difference.
I'm not an engineer; I'm not learned in CS. So some
clarification on this would be nice: if you're pulling in C
code, or any code written in an unsafe language, wouldn't the
developers doing such a thing already be aware they need to do
their due diligence? Foreign code isn't just going to magically
appear in your codebase, right? Maybe through dependencies, but
one should check those too, eh? (And if the dependency tree is
needlessly large, then the language has another, maybe bigger,
problem à la the NPM ecosystem.)
Even if you did review your code *and* all of your dependencies,
if you did it before DIP 1028 was accepted (i.e., any time in the
last 10 years or so), you may have deliberately left external
@system functions un-annotated, because @system was the default.
In fact, I *know* that people have done this, because I've been
running my patched version of the compiler [1] against the dmd,
druntime, and phobos codebases, and I have found an enormous
number of such un-annotated declarations. Here are just a few of
them in druntime:
https://github.com/dlang/druntime/pull/3117
Lots and lots of projects in the D ecosystem are going to need
similar patches to be compatible with DIP 1028. And I don't think
it's realistic to expect people to make these changes without
some kind of help from the tooling.
[1] https://github.com/dlang/dmd/pull/11176