Bug 17748 – extern(C) do nothing on struct methods

struct S { extern(C) void foo(){} } DMD generates D mangled name instead of C's `_foo`.

C doesn't support methods. So I guess this should be an error instead of silently falling back to extern(D).

I agree with @kinke, the example above shouldn't compile.

The compiler tries to do the mangling for the specified linkage attribute and if it cannot, it will just go with the default link attribute which is D. In my opinion, this is the correct behavior, since it is not the compiler's job to check the correctness of a code which is not D code.

(In reply to RazvanN from comment #3) > In my opinion, this is the correct behavior, since it is not the > compiler's job to check the correctness of a code which is not D code. I strongly disagree. It *is* D code, otherwise it wouldn't be fed to the D compiler. Doesn't matter whether it's defined in D or somewhere external, a declaration in D suffices.

But the code is in D - the compiler isn't being asked to check any code that isn't D code. There are basically three options here: 1) Mangle S.foo as '_foo', and have it behave like an extern(C) function taking an S as its first parameter. 2) Disallow the code, via a compilation error or at the very least a warning. 3) Ignore 'extern(C)' and generate code that behaves counter to the programmer's expectations. Note that none of these options require the compiler to check the correctness of any code that is not D code. Currently, as this bug report points out, the option chosen is 3). This is the worst option, as it leads to an error at link-time, which might be in a dynamic linker at some unspecified later point. Since the compiler already knows that it won't mangle the name correctly, implementing 2) should be little work, and provide great help to the poor programmer who's bitten by this bug. Since pragma(mangle) works on struct methods, implementing 1) should also not be an insurmountable problem, but since C does not have methods, the calling convention is basically unspecified, and something will need to be done in that case. Not sure how much work this would be. The current solution is basically the worst possible, and for no good reason. The only way it could be worse is if it mangled the name as requested and still used the D calling convention.

Thank you all for the explanations. I'm on this.

https://dlang.slack.com/archives/C1ZDHBB2S/p1508243056000454 IIUC, `extern(C)` is simply ignored for non-static member methods atm., neither changes mangling nor the method ABI. The only case where that is helpful is with blunt struct scope `extern(C)`. ```struct S { extern(C): // just everything static void foo() { } float foo(int a, float b) { return a + b; } } ``` At a first look it seems reasonable to deprecate using `extern(C)` on non-static member methods, and require people to rewrite above code to ```struct S { extern(C) static void foo() { } float foo(int a, float b) { return a + b; } } ``` . Static methods should support extern(C) calling convention, and in that case it seems reasonable to stick with the current behavior, to only affect the calling convention, but not the mangling.

Per the discussion in [1], closing the issue as invalid. [1] https://github.com/dlang/dmd/pull/7229

What is the reason for breakage? For convenience attributes applied in bulk silently skip members they are not applicable to: This works: --- struct A { final: int a; } --- But if applied on per member basis they give error: --- struct A { final int a; //error } ---