@safe by default

[Quirin Schroll]

On Monday, 10 June 2024 at 15:12:28 UTC, Quirin Schroll wrote:
> 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.

Addendum to:

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

Missing bits:

This affects all attributes, not just `@safe`.

The compiler might be able to do the grepping. By that I mean not 
actual grepping, it must be fool-proof, i.e. use the D parser and 
make sure the symbols are really the same. Other than that, I see 
no way to allow non-D prototypes be annotated `@safe`.