I can see that happening. A simple example would be:
extern (C) void free(void* p);
...
free(p);
free(p);
The thing is, you are no worse off than now. If free() can be
misused by calling it from system code, it can be misused by
calling it from safe code.
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.
If the situation in using new features is indeed as dire as you
fear, a better alternative would have been to just reject the
DIP. Then there would be less `@safe` code, but at least you
could trust `@safe` much more, due to the above phenomenon. I do
think there would have been a way to have `@safe` by default even
with the assumptions you made about it's abuse, but the DIP
reviews are over so I don't think it's worth explaining anymore.
But at least you gave the reasonable rationale we wanted. Thank
you.
