@safe by default

[Richard (Rikki) Andrew Cattermole]

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.

The only thing special about them is the convention that they should 
have methods discarded and that they get priority over .d files. In all 
other ways the are the same as .d files.

The .di generator currently runs _before_ semantic, this means no 
inferred attributes get emitted. If you move it to after semantic 
(assuming no other issues lol) scope and return will be emitted in the 
wrong order messing up mangling.

Basically right now the .di generator can't be used. I am working on 
fixing most of the blocking issues, but unfortunately I am going to hand 
it off due to some semantic rewrites that I cannot fix.

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.