@safe by default

[Quirin Schroll]

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.

For `extern(C/C++)` functions implemented in D, whether the .di 
file contains contains `@safe` or `@trusted` declarations doesn’t 
really make a difference. For callers, they’re the same. They 
also mangle the same. There may be a difference what reflection 
sees, though.

I notice one issue, that `@trusted` is not the same as `@safe` 
from the caller perspective. In `extern(D)`, they also mangle 
differently, which is fine but weird.

I noticed that this does not compile:
```d
extern(C) void f() @trusted;
extern(C) void f() @safe { }
void main() { f(); } // error: `f` ambiguous
```

This could be an issue for the D module that defines the 
function, maybe it isn’t. If it is, I guess that could be 
changed, i.e. for `extern(C/C++)` make the compiler realize that 
function declarations only differing in attributes refer to the 
same function. I cannot imagine someone relies on this being an 
error.