DIP1028 - Rationale for accepting as is

[Steven Schveighoffer]

On 5/22/20 6:13 AM, Dukc wrote:
> Wrong :-(. The scenario is this:
> 
> ```
> @safe void foo(int* p)
> {   import customfreefunction.noannotations;
>      p.free;
>      p.free;
> }
> ```
> 
> Now, this will not compile, because `free` is `@system`. But if `free` 
> is in unannotated module, this will compile after the DIP 
> implementation. Obviously not with the standard library `free` because 
> it'll be annotated `@system` anyway, but with some custom `free` 
> function this is an issue.

I want to interject slightly to say that this isn't the exact problem. 
The exact problem is that today `foo` is NOT marked @safe (or else it 
wouldn't compile). But after the DIP it will be IMPLICITLY marked safe, 
and so will `free`. Thereby silently migrating all system code that 
should actually be (and was INTENDED to be) system code straight to safe 
code without any warnings.

This in itself isn't a problem, code that compiled yesterday compiles 
today, and is just as bad.

The true problem is that after the DIP is implemented, new users will 
use foo within safe code they INTEND to be safe, and will be none the 
wiser that it's not.

The scenario I imagine is that unadorned code will exist for years as 
@safe (implicitly) and only after years of being depended on as @safe 
code, is discovered to be completely unsafe, and the only way to fix is 
to break existing usage. Or worse, it's not discovered and then D's 
already shaky reputation for @safe code is destroyed when a hacker 
exploits the memory corruption in fully-marked @safe code.

The actual bug may be extremely subtle. We have code in phobos that does 
stuff like:

static if(is(typeof(() @safe { obj.doSomething(); }))) obj.doSomething();
else doSomethingSafely(obj);

which will silently switch to using unsafe (but marked safe) mechanisms 
(for optimization).

-Steve