DIP1028 - Rationale for accepting as is

[Andrej Mitrovic]

On Wednesday, 27 May 2020 at 09:50:50 UTC, Walter Bright wrote:
> Un-annotated C declarations should be a red flag to any 
> competent QA team. Recognizing a false @trusted is a whole lot 
> harder.

Is the actual problem those `@trusted:` declarations at the top 
of C headers?

There could be a simple solution to that:

Ban `@trusted:` and `@trusted { }` which apply to multiple 
symbols. Only allow `@trusted` to apply to a single symbol. For 
example:

---
@trusted:

extern(C) void memcpy (void*, void*, size_t);
extern(C) void write42 (void*);
---

Error.

---
@trusted extern(C) void memcpy (void*, void*, size_t);
@trusted extern(C) void write42 (void*);
---

OK, compiles. The bindings author has clearly added @trusted 
manually to each symbol.

Obviously there are escape hatches like mixins, code generation, 
etc.