Rationale for accepting DIP 1028 as is

[Johannes T]

On Wednesday, 27 May 2020 at 10:51:54 UTC, Walter Bright wrote:
> [..]

I was reading Bastiaan's inspiring ideas about provable 
verification of @trusted and something occurred to me. If we are 
serious about safety, we should consider @trusted annotation on 
extern C harmful. It provides little value and might be 
misleading like a bad comment:
// only call once, second call leaks
void waitForClose(size_t msTimeout);
The implementation was rewritten long ago, no one bothered to 
remove the remark.
The trustworthiness of extern code can be assessed by audit. It 
can only be set in stone by additional tools. git can nail down 
the version of a verified function in the CMake list. The 
compiler can't know what we are linking against or what's loaded 
at runtime.
@trusted extern C is meaningless. Pre DIP1028 we had to put it in 
for @safe code to compile.
I'm not sure how @system fits into this. It gets outdated the 
same way @trusted does.