On 5/23/20 6:55 AM, Dukc wrote:
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.
This is fine, the code *is* @system. There's nothing wrong with @system
code in D.
What is wrong is blanket assumption of @safety. In this case, people who
actually care about memory safety want to be sure that @safe functions
are actually @safe. If you lie about that, then the whole system breaks
down. @safe just becomes a convention, and really everything just has to
be manually checked.
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!
I understand what you are saying, you want the @safety checking in your
code, but do not want to deal with the hassle of making special wrappers.
And let's be honest here, if you are OK with it, putting @trusted: at
the top of your extern(C) functions is fine with me. At least that's not
a lie.
What is not fine is having the compiler do it for you so nary a @trusted
marking is in sight. I don't really understand the draw of that.
-Steve
