Greenwashing: best practices

[Johannes T]

I was searching for ways to mitigate DIP's 1028 greenwashing 
concerns without resorting to @safe extern. It turns out, D 
already has tools to address that. It's a matter of recognizing 
and promoting best practices. Allow me to elaborate.

Verified C functions require @trusted declaration when used in 
safe code. It's a slight antipattern, similar to a bad comment:
// implementation looks safe
ssize_t recv(void*, size_t);

Yes, @trusted is parsed and can be searched, that's not the 
point. It's too far from the source code. What version was 
vetted? Are we linking against an older one that leaked? Hard to 
say without checking. This leads to the first advice:

Declarations should reside in .di files and not be scattered 
throughout D code. It allows us to keep .di closer to the library 
and version it separately. If the version changes, there is no 
need to search for affected D sources.

Many bindings already do that. I wasn't aware of it and just used 
extern(C) as needed.

Let's assume we've created a .di file with some internal C 
backend stuff. Trying to call it doesn't compile. The next advice 
could be:

To force unchecked functions to compile, the corresponding 
declarations should be surrounded by @trusted { } block. The 
block suggests it was rubber-stamped without audit. It's also the 
path of least resistance for multiple functions. @trusted should 
only be added to a single declaration if it was verified.

I imagine being a C++ programmer trying out D and don't see much 
inconvenience following this. More importantly, when the program 
crashes, I would remember adding @trusted { } and can't blame D's 
safety annotation.