On Saturday, 1 June 2024 at 21:06:05 UTC, Timon Gehr wrote:
> On 5/30/24 20:35, Atila Neves wrote:
>> https://github.com/atilaneves/DIPs/blob/safe-by-default/safe-by-default.md
>> 
>> Destroy!
>
> - I think even more important than the default is the ability to change the default (e.g. `default(@safe):`). This does not exist currently, but it would be required for easy migration.

That's a good point, but: do we only do it for this attribute or for the others as well?

> - There is not really any value in being able to write `@safe extern(C)/extern(C++)` prototypes. It's wrong and any linter would need to have a warning for it. I would just require an explicit `@system` or `@trusted` annotation. Note that for `extern(C)/extern(C++)` prototypes, `@safe` and `@trusted` have _the same semantics and interpretation_, but only one of them looks adequately dangerous and is easy to grep.

I get this, but the issue is that those functions might actually be written in D.

> - The DIP should clarify whether annotations like `@safe:` apply to prototypes or whether prototypes always need an individual annotation.

Added.

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.

On 6/3/24 17:55, Atila Neves wrote:
>> - There is not really any value in being able to write `@safe extern(C)/extern(C++)` prototypes. It's wrong and any linter would need to have a warning for it. I would just require an explicit `@system` or `@trusted` annotation. Note that for `extern(C)/extern(C++)` prototypes, `@safe` and `@trusted` have _the same semantics and interpretation_, but only one of them looks adequately dangerous and is easy to grep.
> 
> I get this, but the issue is that those functions might actually be written in D.

Why is this an issue?

On Thursday, 6 June 2024 at 17:01:05 UTC, Timon Gehr wrote:
> On 6/3/24 17:55, Atila Neves wrote:
>>> - There is not really any value in being able to write `@safe extern(C)/extern(C++)` prototypes. It's wrong and any linter would need to have a warning for it. I would just require an explicit `@system` or `@trusted` annotation. Note that for `extern(C)/extern(C++)` prototypes, `@safe` and `@trusted` have _the same semantics and interpretation_, but only one of them looks adequately dangerous and is easy to grep.
>> 
>> I get this, but the issue is that those functions might actually be written in D.
>
> Why is this an issue?

The compiler would have access to the body and so would verify its @safe-ness.

On 6/7/24 02:58, Atila Neves wrote:
> On Thursday, 6 June 2024 at 17:01:05 UTC, Timon Gehr wrote:
>> On 6/3/24 17:55, Atila Neves wrote:
>>>> - There is not really any value in being able to write `@safe extern(C)/extern(C++)` prototypes. It's wrong and any linter would need to have a warning for it. I would just require an explicit `@system` or `@trusted` annotation. Note that for `extern(C)/extern(C++)` prototypes, `@safe` and `@trusted` have _the same semantics and interpretation_, but only one of them looks adequately dangerous and is easy to grep.
>>>
>>> I get this, but the issue is that those functions might actually be written in D.
>>
>> Why is this an issue?
> 
> The compiler would have access to the body and so would verify its @safe-ness.

A function prototype does not have a body and the actual body may be in another compilation unit. For `extern(D)` the mangled name gives some assurances, but not for `extern(C)` and `extern(C++)`.

I guess maybe an additional alternative name can be given to `@safe` `extern(C)` functions, but I doubt that linker errors are a great UX for safety checks.

Timon Gehr kirjoitti 7.6.2024 klo 17.25:
> On 6/7/24 02:58, Atila Neves wrote:
>> On Thursday, 6 June 2024 at 17:01:05 UTC, Timon Gehr wrote:
>>> On 6/3/24 17:55, Atila Neves wrote:
>>>>> - There is not really any value in being able to write `@safe extern(C)/extern(C++)` prototypes. It's wrong and any linter would need to have a warning for it. I would just require an explicit `@system` or `@trusted` annotation. Note that for `extern(C)/extern(C++)` prototypes, `@safe` and `@trusted` have _the same semantics and interpretation_, but only one of them looks adequately dangerous and is easy to grep.
>>>>
>>>> I get this, but the issue is that those functions might actually be written in D.
>>>
>>> Why is this an issue?
>>
>> The compiler would have access to the body and so would verify its @safe-ness.
> 
> A function prototype does not have a body and the actual body may be in another compilation unit. For `extern(D)` the mangled name gives some assurances, but not for `extern(C)` and `extern(C++)`.
> 
> I guess maybe an additional alternative name can be given to `@safe` `extern(C)` functions, but I doubt that linker errors are a great UX for safety checks.

When Átila wrote his last reply I was still agreeing with him. Why? I missed that you, in your earlier post, wrote specifically about function prototypes, not any C/C++ linked functions. I guess Átila did too - I can't see why else he would have thought the compiler has access to the function body.

If I'm assessing this right, you're actually in agreement with each other. The only disagreement you maybe have is whether it's this DIP or some later alternative that should change the rules for those functions.