DIP1028 - Rationale for accepting as is

[Timon Gehr]

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.