DIP1028 - Rationale for accepting as is

[Dukc]

The more I think of Atila's and Walter's responses, the more they 
are starting to make sense.

When I look my own code that uses the Nuklear GUI library, 
written in C, it's all `@system`. I have not had the time to make 
`@trusted` wrappers over the BindBC-nuklear API, so I did what 
tends to occur to us as the next best thing: resign and make the 
whole client code `@system`. Just making `@trusted` wrappers over 
BindBC-nuklear seemed to me as inresponsible use of the 
attribute. And reading this theard, it would seem like most of 
you would agree.

But when I think it, what I have accomplised from avoiding that 
antipattern? The only difference is, that if my D code does 
something `@system`, it'll remain under the radar. So I'm worse 
off than had I submitted to the antipattern!

Now, were I designing a library instead of an application, of 
course I should not pass such client code as `@safe`, regardless 
of which of those two ways I choose. But I think the correct way 
would be to mark the API functions as @system. Then it's be best 
of both cheap tricks: The compiler will verify my D code from 
mistakes, but I won't pretend that my code is truly `@safe`.