DIP1028 - Rationale for accepting as is
bachmeier
no at spam.net
Fri May 22 14:49:36 UTC 2020
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.
More information about the Digitalmars-d-announce
mailing list