DIP1028 - Rationale for accepting as is

[Steven Schveighoffer]

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