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

Reply via email to