DIP1028 - Rationale for accepting as is

[Timon Gehr]

On 22.05.20 15:58, bachmeier wrote:
> ...
> 
> Honest question: What is the use case for an 
> absolutely-positively-has-to-be-safe program that calls C code? Why 
> would anyone ever do that? C is not and will never be a safe language. 
> "Someone looked at that blob of horrendous C code and thinks it's safe" 
> does not inspire confidence. Why not rewrite the code in D (or Rust or 
> Haskell or whatever) if safety is that critical?

Honesty is what's critical. The annotations should mean what they are 
advertised to mean and making those meanings as simple as possible makes 
them easier to explain. As things stand, @safe can mean that someone 
accidentally or historically did not annotate an extern(C) prototype and 
an unsafe API a few calls up was ultimately exposed with the @safe 
attribute because the compiler never complained.

How would you feel if you never intended to expose a @safe interface, 
but someone imported your library after determining it contained no 
@trusted annotations (following the advice of articles on @safe), relied 
on the @safe annotation and then had weird sporadic memory corruption 
issues in production that took them months to ultimately trace back to 
your library? Would you feel responsible or would you rather put the 
blame on Walter?