[Issue 17748] extern(C) do nothing on struct methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #9 from anonymous4  ---
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
}
---

--

[Issue 17748] extern(C) do nothing on struct methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from RazvanN  ---
Per the discussion in [1], closing the issue as invalid.

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

--

[Issue 17748] extern(C) do nothing on struct methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #7 from Martin Nowak  ---
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.

--

[Issue 17748] extern(C) do nothing on struct methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #6 from RazvanN  ---
Thank you all for the explanations. I'm on this.

--

[Issue 17748] extern(C) do nothing on struct methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #5 from Simen Kjaeraas  ---
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.

--

[Issue 17748] extern(C) do nothing on struct methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

--- Comment #4 from ki...@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.

--

[Issue 17748] extern(C) do nothing on struct methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #3 from RazvanN  ---
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.

--

[Issue 17748] extern(C) do nothing on struct methods

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

ZombineDev  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||petar.p.ki...@gmail.com
   Severity|major   |normal

--- Comment #2 from ZombineDev  ---
I agree with @kinke, the example above shouldn't compile.

--

[Issue 17748] extern(C) do nothing on struct methods

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17748

ki...@gmx.net changed:

   What|Removed |Added

 CC||ki...@gmx.net

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

--