On 22.05.20 16:49, bachmeier wrote:
On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote:
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.
In my opinion, the only advantage of @safe is that the compiler has
checked the code and determines that it only does things considered
safe.
Wrong, but let's roll with that.
I don't see that marking an extern(C) function @trusted buys you
anything, at least not until you can provide a compiler guarantee for
arbitrary C code.
It buys you the ability to call that function from @safe code. Clearly
you can't mark it @safe because the compiler has not checked it.
