@safe by default

[Quirin Schroll]

On Tuesday, 4 June 2024 at 20:33:07 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 05/06/2024 12:13 AM, Quirin Schroll wrote:
>> On Monday, 3 June 2024 at 15:56:05 UTC, Atila Neves wrote:
>>> On Monday, 3 June 2024 at 11:08:36 UTC, Quirin Schroll wrote:
>>>> On Thursday, 30 May 2024 at 18:35:36 UTC, Atila Neves wrote:
>>>>> [...]
>>>>
>>>> Because of a lack of mangling, `extern(X)` where `X` isn’t 
>>>> `D` shouldn’t ever be allowed to be annotated `@safe` unless 
>>>> it’s a definition.
>>>>
>>>> [...]
>>>
>>> I could see changing it to this; but what if it's writen in D 
>>> and someone wants to use a .di file?
>> 
>> TBH, I don’t know what .di files really are. AFAIK, they’re 
>> basically what a header file in C/C++ is. They contain 
>> declarations. The biggest difference to C/C++ is that .di 
>> files are compiler generated and a programmer might 
>> occasionally read them, but essentially never write or edit 
>> one. Correct me if I’m wrong.
>
> .di files are currently all hand written.
>
> […]
>
> A quick look on ABI page, both ``@safe`` and ``@trusted`` get 
> name mangled differently.
>
> https://dlang.org/spec/abi.html#FuncAttrTrusted
>
> So yes we'd have to allow ``@safe`` on function declarations 
> without bodies unfortunately.

I’m not referring to `extern(D)` functions. I knew those have 
attributes mangled into them, so you’ll get linker errors on an 
attribute mismatch between a function’s prototype and its 
definition. The issue is, for `extern(C/C++)` functions, 
attributes aren’t mangled into it, so the linker is blind to the 
mismatch.

Of course, linker errors aren’t great, but still a lot better 
than UB at runtime.

If .di files are hand-written, we must absolutely not allow 
`@safe` annotations on `extern(C/C++)` function declarations. 
Those must all be `@trusted`, even if the validation by the 
programmer only requires grepping the function name and observing 
that the function definition (the implementation) is annotated 
`@safe`, so the actual, difficult validation is done by the 
compiler. However, `@trusted` is warranted, as when the 
implementation isn’t annotated `@safe` (either because it’s not 
annotated or is in another language entirely), it simply may not 
be safe, and therefore, a `@safe` function declaration in a .di 
file would be a lie, and the bad thing about that is that it’s 
not going to be caught by the compiler or linker.

The `@trusted` attribute only means that *some* programmer-side 
verification established the function is actually safe. It does 
not mean the verification can’t be as simple as a grep.

In fact, if .di files are hand written, changing `@safe` to 
`@trusted` after copying a function signature isn’t too wild to 
ask. The simple fact is, on non-D functions, `@safe` can’t be 
verified except on function definitions, and therefore can’t be 
used. @Átila: Making exceptions to `@safe` so that it isn’t 
fool-proof would be a disaster to D’s marketability.