DIP1028 - Rationale for accepting as is

[bachmeier]

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.
>
> If the compiler was honest and told me that my code was unsafe, 
> I'd be able to make an informed decision to either (a) accept 
> the lack of safety, or (b) do the additional work needed to 
> make it safe. As-is, DIP 1028 takes that choice away from me, 
> and I am forced to accept a lack of safety whether I want to or 
> not. At that point, why not use C?

If you're compiling a program that calls into C, you know that's 
what you're doing, so you know you've given up any guarantees of 
safety. Back in the early days of Rust, someone made a comment 
along the lines of Rust being a language to rewrite C code in, 
not to use to call C code. D has, to this point, been a language 
designed to interoperate easily with C code. I personally don't 
care about safety guarantees at all. It's not obvious to me that 
guaranteed safety at all costs is the way to go - especially 
considering the degree to which that breaks from current behavior.