DIP1028 - Rationale for accepting as is

[Dukc]

> 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.