DIP1028 - Rationale for accepting as is

[Atila Neves]

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.