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?
