@safe by default

[Dukc]

Timon Gehr kirjoitti 7.6.2024 klo 17.25:
> On 6/7/24 02:58, Atila Neves wrote:
>> On Thursday, 6 June 2024 at 17:01:05 UTC, Timon Gehr wrote:
>>> On 6/3/24 17:55, Atila Neves wrote:
>>>>> - There is not really any value in being able to write `@safe 
>>>>> extern(C)/extern(C++)` prototypes. It's wrong and any linter would 
>>>>> need to have a warning for it. I would just require an explicit 
>>>>> `@system` or `@trusted` annotation. Note that for 
>>>>> `extern(C)/extern(C++)` prototypes, `@safe` and `@trusted` have 
>>>>> _the same semantics and interpretation_, but only one of them looks 
>>>>> adequately dangerous and is easy to grep.
>>>>
>>>> I get this, but the issue is that those functions might actually be 
>>>> written in D.
>>>
>>> Why is this an issue?
>>
>> The compiler would have access to the body and so would verify its 
>> @safe-ness.
> 
> A function prototype does not have a body and the actual body may be in 
> another compilation unit. For `extern(D)` the mangled name gives some 
> assurances, but not for `extern(C)` and `extern(C++)`.
> 
> I guess maybe an additional alternative name can be given to `@safe` 
> `extern(C)` functions, but I doubt that linker errors are a great UX for 
> safety checks.

When Átila wrote his last reply I was still agreeing with him. Why? I 
missed that you, in your earlier post, wrote specifically about function 
prototypes, not any C/C++ linked functions. I guess Átila did too - I 
can't see why else he would have thought the compiler has access to the 
function body.

If I'm assessing this right, you're actually in agreement with each 
other. The only disagreement you maybe have is whether it's this DIP or 
some later alternative that should change the rules for those functions.