Thread overview
[Issue 17748] extern(C) do nothing on struct methods
Aug 12, 2017
kinke@gmx.net
Aug 13, 2017
ZombineDev
Oct 16, 2017
RazvanN
Oct 16, 2017
kinke@gmx.net
Oct 16, 2017
Simen Kjaeraas
Oct 16, 2017
RazvanN
Oct 17, 2017
Martin Nowak
Oct 19, 2017
RazvanN
Oct 20, 2017
anonymous4
August 12, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

kinke@gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke@gmx.net ---
C doesn't support methods. So I guess this should be an error instead of silently falling back to extern(D).

--
August 13, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
                 CC|                            |petar.p.kirov@gmail.com
           Severity|major                       |normal

--- Comment #2 from ZombineDev <petar.p.kirov@gmail.com> ---
I agree with @kinke, the example above shouldn't compile.

--
October 16, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #3 from RazvanN <razvan.nitu1305@gmail.com> ---
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.

--
October 16, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #4 from kinke@gmx.net ---
(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.

--
October 16, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #5 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
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.

--
October 16, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #6 from RazvanN <razvan.nitu1305@gmail.com> ---
Thank you all for the explanations. I'm on this.

--
October 17, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #7 from Martin Nowak <code@dawg.eu> ---
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.

--
October 19, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from RazvanN <razvan.nitu1305@gmail.com> ---
Per the discussion in [1], closing the issue as invalid.

[1] https://github.com/dlang/dmd/pull/7229

--
October 20, 2017
https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #9 from anonymous4 <dfj1esp02@sneakemail.com> ---
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
}
---

--