DIP1028 - Rationale for accepting as is

[Paolo Invernizzi]

On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:

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

I really don't understand, there's no "maybe" memory safety: if 
there's no time to spend for memory safety in a project, why care?

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

I disagree: if you *really* want to use @safe in the rest of the 
codebase, just mark the binding as trusted, raising your hand 
towards reviewers (or everybody is interested in checking the 
memory safety of the project codebase), writing in the comment 
that "you" have decided to spend no time in a proper wrapping, 
and the motivations.

Let the reviewers and the other guys out there just decide what 
to do with your codebase.

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

It's not an anti pattern, it clearly show your motivation, that's 
all about @trusted. May also write a big *disclaimer* in the 
README pointing to the pitfalls