DIP1028 - Rationale for accepting as is

[bachmeier]

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. 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.