On Friday, 22 May 2020 at 14:13:20 UTC, Paul Backus wrote:
On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into existing, correct D code.
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?
The problem isn't that safety is critical, it's that the D
compiler is lying to me about the safety of my code.
I understand your argument, especially since I wrote nearly
identical words weeks ago.
For me, what it boils down to is this: currently the compiler
isn't doing what it could because of the @system default. I work
on a D codebase that can't be called from a @safe unittest and we
could (probably are) be hiding bugs due to this.
Flipping the default will cause more incorrect code to fail to
compile. Yes, there's a cost, which is carefully vetting
extern(C) and extern(C++) declarations. The decision came down to
finding this an acceptable trade-off.
