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