DIP1028 - Rationale for accepting as is

[Paul Backus]

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