www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - extern(C) names are being mangled; that's crazy, Walter says I'm crazy

reply Manu <turkeyman gmail.com> writes:
https://issues.dlang.org/show_bug.cgi?id=20012

I need to know who is the crazy one here?
I can't believe the idea that extern(C) functions being mangled to
un-knowable generated names is what any sane user would ever expect.

Surely extern(C) means extern(C)?

I'd like a poll here...
Jul 23 2019
next sibling parent Newbie2019 <newbie2019 gmail.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

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

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...


I just has the same problem yesterday, I just fix it by move the 
extern(C) out from mixin template to workaround.
Jul 23 2019
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

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

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...


Just for comparison, here's what Rust does: 
https://doc.rust-lang.org/std/keyword.extern.html

I like the fact that `extern` and `mangle` mean different things, 
but I don't like the way D currently implements it. Here's how I 
would design it.

1. `pragma(mangle)` should come in more forms.
   a. `pragma(mangle, C)` will mangle according to C rules
   b. `pragma(mangle, C++)` will mangle according to C++ rules
   c. `pragma(mangle, D)` will mangle according to D rules
   d. `pragma(mangle, "foo")` will mangle explicitly

2. `extern` should default the mangling to one of the above
   a. `extern(C)` should mean `extern(C) pragma(mangle, C)`
   b. `extern(C++)` should mean `extern(C++) pragma(mangle, C++)`
   c. `extern(D)` should mean `extern(D) pragma(mangle, D)`

So, this code...
struct S
{
     extern(C) void foo() { }
}
... would actually translate into...
struct S
{
     extern(C) pragma(mangle, C) void foo() { }
}
... which, IIUC, would ultimately mean...
struct S
{
     extern(C) pragma(mangle, "foo") void foo() { }
}

This code...
mixin template M()
{
     extern(C) void fun() {}
}
mixin M!();
... would result in ...
{
     extern(C) pragma(mangle, C) void fun() {}
}
... which, in turn, would result in ...
{
     extern(C) pragma(mangle, "fun") void fun() {}
}

If the user instantiates the mixin multiple times, they will get 
duplicate symbol errors from the linker.  If they wanted to take 
control, they would have to opt into a different mangling scheme 
such as...

mixin template M()
{
     extern(C) pragma(mangle, D) void fun() {}
}

... which I, IIUC, would result in the current behavior.

If the compiler cannot deterministically compute the mangling 
scheme specified because there is no translation from the D code, 
the compiler would emit a meaningful error telling the user so, 
and they may be able to work around it with the explicit 
`pragma(mangle)` form.

IMO, that would be the most practical, covering the most common 
cases, and would also be the least surprising.

So, in general, I side with Manu here, but I expect a little more 
from the language.

Mike
Jul 23 2019
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Mike Franklin wrote:


    a. `extern(C)` should mean `extern(C) pragma(mangle, C)`


then your code samples cannot be compiled at all, because each `extern(C)` 
will in turn be expaned to`extern(C) pragma(mangle, C)`, and the loop will 
go on. also, i won't even try to explain to somebody that "`extern(C)` 
means `extern(C) blah-blah`, but you see, the second "extern" is special, 
because... ahem... just because."
Jul 24 2019
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 24 July 2019 at 09:44:19 UTC, ketmar wrote:

Nice to see you here again, ketmar ...
Jul 24 2019
parent ketmar <ketmar ketmar.no-ip.org> writes:
Paolo Invernizzi wrote:


 On Wednesday, 24 July 2019 at 09:44:19 UTC, ketmar wrote:

 Nice to see you here again, ketmar ...


thank you. i'm still lurking here, only don't have enough time for D these 
days. but this issue managed to trigger me somehow.
Jul 24 2019
prev sibling parent sarn <sarn theartofmachinery.com> writes:
On Wednesday, 24 July 2019 at 06:25:50 UTC, Mike Franklin wrote:

 1. `pragma(mangle)` should come in more forms.
   a. `pragma(mangle, C)` will mangle according to C rules
   b. `pragma(mangle, C++)` will mangle according to C++ rules
   c. `pragma(mangle, D)` will mangle according to D rules
   d. `pragma(mangle, "foo")` will mangle explicitly

 2. `extern` should default the mangling to one of the above
   a. `extern(C)` should mean `extern(C) pragma(mangle, C)`
   b. `extern(C++)` should mean `extern(C++) pragma(mangle, C++)`
   c. `extern(D)` should mean `extern(D) pragma(mangle, D)`


Yeah.  Walter's approach is the only one that works well without 
a pragma(mangle, D), but I think pragma(mangle, D) is a better 
idea.
Jul 24 2019
prev sibling next sibling parent aliak <something something.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

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

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...


I'm not sure.

If there's an extern(C) in a mixin template, the prime purpose of 
which is to be reusable, does it make sense to instantiate that 
multiple times? Won't there then be multiple C-compatible symbols 
of the same thing, but with different semantics based on the 
context of the mixin template?
Jul 24 2019
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
I never called you crazy, or anything remotely like that.
Jul 24 2019
parent reply Manu <turkeyman gmail.com> writes:
On Wed., 24 Jul. 2019, 2:20 am Walter Bright via Digitalmars-d, <
digitalmars-d puremagic.com> wrote:


 I never called you crazy, or anything remotely like that.


Just kill me and bring me peace.
I lose my mind trying to argue with you, and get so frustrated and angry, I
just have to take a week or 2 timeout.
I feel like this community just grinds my life away slowly but steadily and
I hate participating, but I'm in too deep. I just want to kick my goal and
get on with my job!
Everything is just so hard, and so very weird.
Why can't stuff just be predictable? Why does everything have to have weird
special case rules and strange edge cases?

My biggest trouble with D recently had been trying to explain it to people,
and make them not lose confidence when they run in to a long series of
stuff like this.
I have to try and explain weird shit like it's got a good reason with a
straight face, and I just can't do that on so many accounts!
This is D's biggest enemy in 2019, I'm sure of it.

Anyway... I'm sorry, this is actually a distraction. I've managed to lose
my laser focus on shared stuff. That's what I need today to progress.






 Jul 24 2019



 next sibling parent  FeepingCreature <feepingcreature gmail.com>  writes:


On Wednesday, 24 July 2019 at 09:56:50 UTC, Manu wrote:

 On Wed., 24 Jul. 2019, 2:20 am Walter Bright via Digitalmars-d, 
 < digitalmars-d puremagic.com> wrote:


 I never called you crazy, or anything remotely like that.


 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated 
 and angry, I
 just have to take a week or 2 timeout.
 I feel like this community just grinds my life away slowly but 
 steadily and
 I hate participating, but I'm in too deep. I just want to kick 
 my goal and
 get on with my job!
 Everything is just so hard, and so very weird.
 Why can't stuff just be predictable? Why does everything have 
 to have weird
 special case rules and strange edge cases?

 My biggest trouble with D recently had been trying to explain 
 it to people,
 and make them not lose confidence when they run in to a long 
 series of
 stuff like this.
 I have to try and explain weird shit like it's got a good 
 reason with a
 straight face, and I just can't do that on so many accounts!
 This is D's biggest enemy in 2019, I'm sure of it.


I definitely agree that D as a language has taken on way way too 
much complexity, and is taking on more complexity all the time, 
it's not sustainable and we *need* to get on top of it, somehow, 
though I have no idea what can be done.

That said, imo you should *definitely* take a break on this; you 
sound like you're one negative feedback away from burnout.



 Jul 24 2019



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/24/2019 2:56 AM, Manu wrote:

 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated and angry, I
just 
 have to take a week or 2 timeout.


On the other hand, you've gotten:

1. user defined attributes
2. rvalue reference parameters
3. restricted shared access
4. mixin types
5. the namespace string thing



 Jul 24 2019



 next sibling parent  SashaGreat <s g.com>  writes:


On Wednesday, 24 July 2019 at 23:03:59 UTC, Walter Bright wrote:

 On 7/24/2019 2:56 AM, Manu wrote:

 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated 
 and angry, I just have to take a week or 2 timeout.


 On the other hand, you've gotten:

 1. user defined attributes
 2. rvalue reference parameters
 3. restricted shared access
 4. mixin types
 5. the namespace string thing


Touché!



 Jul 24 2019



prev sibling next sibling parent  Manu <turkeyman gmail.com>  writes:


On Wed., 24 Jul. 2019, 4:05 pm Walter Bright via Digitalmars-d, <
digitalmars-d puremagic.com> wrote:


 On 7/24/2019 2:56 AM, Manu wrote:

 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated and


 angry, I just

 have to take a week or 2 timeout.


 On the other hand, you've gotten:

 1. user defined attributes
 2. rvalue reference parameters
 3. restricted shared access
 4. mixin types
 5. the namespace string thing


Don't forget extern(C++),  nogc, win64... ;)



More than 10 years and a crazy amount of time arguing for some of those
though!

But this isn't like that... This isn't in the major or controversial
feature category, it's just a bug... but apparently it's not; it's by
design, and the design is great.






 Jul 24 2019



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/24/2019 4:03 PM, Walter Bright wrote:

 On the other hand, you've gotten:
 
 1. user defined attributes
 2. rvalue reference parameters
 3. restricted shared access
 4. mixin types
 5. the namespace string thing


6. Windows 64 code generator



 Jul 24 2019



  parent reply Elvis Zhou <elvis.x.zhou gmail.com>  writes:


On Thursday, 25 July 2019 at 03:56:57 UTC, Walter Bright wrote:

 On 7/24/2019 4:03 PM, Walter Bright wrote:

 On the other hand, you've gotten:
 
 1. user defined attributes
 2. rvalue reference parameters
 3. restricted shared access
 4. mixin types
 5. the namespace string thing


 6. Windows 64 code generator


these won't make people come, one weird shit make people go



 Jul 24 2019



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


We expect professional demeanor here, not cussing.



 Jul 25 2019



  parent  Elvis Zhou <elvis.x.zhou gmail.com>  writes:


On Thursday, 25 July 2019 at 07:06:28 UTC, Walter Bright wrote:

 We expect professional demeanor here, not cussing.


No offence here, my point was that, we should first focus on 
fixing those weird things, other than expanding the language with 
new features, since it's obvious once a user quit with bad 
impressions after coming and trying d, he'll never back and we 
lose him forever, the inconsistency Manu mentioned is determined 
to give a bad impression.



 Jul 25 2019



prev sibling  parent reply Jonathan Marler <johnnymarler gmail.com>  writes:


On Wednesday, 24 July 2019 at 09:56:50 UTC, Manu wrote:

 On Wed., 24 Jul. 2019, 2:20 am Walter Bright via Digitalmars-d, 
 < digitalmars-d puremagic.com> wrote:


 I never called you crazy, or anything remotely like that.


 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated 
 and angry, I
 just have to take a week or 2 timeout.
 I feel like this community just grinds my life away slowly but 
 steadily and
 I hate participating, but I'm in too deep. I just want to kick 
 my goal and
 get on with my job!
 Everything is just so hard, and so very weird.
 Why can't stuff just be predictable? Why does everything have 
 to have weird
 special case rules and strange edge cases?

 My biggest trouble with D recently had been trying to explain 
 it to people,
 and make them not lose confidence when they run in to a long 
 series of
 stuff like this.
 I have to try and explain weird shit like it's got a good 
 reason with a
 straight face, and I just can't do that on so many accounts!
 This is D's biggest enemy in 2019, I'm sure of it.

 Anyway... I'm sorry, this is actually a distraction. I've 
 managed to lose my laser focus on shared stuff. That's what I 
 need today to progress.


You're not crazy.  Walter can bey hard to discuss things with.  I 
think he's tired of discussing things after so many years.  He 
tends to ignore most things and only responds to what he thinks 
is important.   If you're feeling burnt out, imagine how he feels 
after all the years he's been doing this.

But know that you're not the only one who feels this way, and 
Walter tends to have a very different viewpoint on things.  So 
don't take it personally, just because he disagrees with you 
doesn't mean you're wrong.

As for this subject, I expect extern (C) to change both the API 
and the mangling, so I would expect the behavior described by 
Manu.  However, I can see use cases for only changing the ABI 
while keeping mangling.  It is very weird that extern (C) affects 
both in normal code, and only the ABI when it's inside a mixin 
template.  Sounds like one of those very odd cases in C++ that 
Scott Meyers would put on one of his slides :)

Dconf 2014 Day 2 Keynote: The Last Thing D Needs -- Scott Meyers
https://www.youtube.com/watch?v=KAWA1DuvCnQ

After reading the thread and thinking on a bit, it seems like it 
would be simpler to have extern (C) do the same thing in all 
cases, which would be to change the ABI and the mangling.  If you 
want D mangling, use mangle(D) or something along with extern (C).



 Jul 24 2019



  parent  Aliak <something something.com>  writes:


On Thursday, 25 July 2019 at 00:24:11 UTC, Jonathan Marler wrote:

 On Wednesday, 24 July 2019 at 09:56:50 UTC, Manu wrote:

 [...]


 You're not crazy.  Walter can bey hard to discuss things with.  
 I think he's tired of discussing things after so many years.  
 He tends to ignore most things and only responds to what he 
 thinks is important.   If you're feeling burnt out, imagine how 
 he feels after all the years he's been doing this.

 But know that you're not the only one who feels this way, and 
 Walter tends to have a very different viewpoint on things.  So 
 don't take it personally, just because he disagrees with you 
 doesn't mean you're wrong.

 As for this subject, I expect extern (C) to change both the API 
 and the mangling, so I would expect the behavior described by 
 Manu.  However, I can see use cases for only changing the ABI 
 while keeping mangling.  It is very weird that extern (C) 
 affects both in normal code, and only the ABI when it's inside 
 a mixin template.  Sounds like one of those very odd cases in 
 C++ that Scott Meyers would put on one of his slides :)

 Dconf 2014 Day 2 Keynote: The Last Thing D Needs -- Scott Meyers
 https://www.youtube.com/watch?v=KAWA1DuvCnQ

 After reading the thread and thinking on a bit, it seems like 
 it would be simpler to have extern (C) do the same thing in all 
 cases, which would be to change the ABI and the mangling.  If 
 you want D mangling, use mangle(D) or something along with 
 extern (C).


Ok, I think after reading this and the bug report, and the 
mentioned uses cases, the callback case is the one that should be 
treated differently, and not the vanilla case. So mangle(D) and 
extern(C) if you want mangling to be different for a C function 
makes things consistent and expected.



 Jul 25 2019



prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

 I can't believe the idea that extern(C) functions being mangled 
 to un-knowable generated names is what any sane user would ever 
 expect.


I have used this pattern for callbacks before without even 
thinking about it, and it just worked. I have also hit some 
annoyance like you saw (and before pragma(mangle) it was really 
annoying, now it is just "huh i forgot to do that").

I wonder if you have ever done a callback use case too and never 
even noticed it exactly because it just works, but then pay a lot 
of attention to this because it doesn't.



 Jul 24 2019



  parent reply Manu <turkeyman gmail.com>  writes:


On Wed, Jul 24, 2019 at 6:55 AM Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

 I can't believe the idea that extern(C) functions being mangled
 to un-knowable generated names is what any sane user would ever
 expect.


 I have used this pattern for callbacks before without even
 thinking about it, and it just worked. I have also hit some
 annoyance like you saw (and before pragma(mangle) it was really
 annoying, now it is just "huh i forgot to do that").


In that callback case, they're effectively anonymously named
functions... The name is irrelevant, and so is the mangling. So that
is the case where pragma(mangle, "IDontCare") should be used. There
shouldn't be edge cases and surprises where extern(C) means something
sometimes, and something else in this weird edge case.


 I wonder if you have ever done a callback use case too and never
 even noticed it exactly because it just works, but then pay a lot
 of attention to this because it doesn't.


I have not. I would *never* expect to declare multiple extern(C)
functions with the same name from the same file and not have link
errors. Nobody would expect that. Mangling extern(C) functions is
ABSOLUTELY NOT extern(C).
If I didn't get the link error I was expecting, I would be angry, and
emitting the exact same rant.
extern(C) shouldn't mean different shit in different cases. I can't
believe anyone thinks that's okay.



 Jul 24 2019



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/24/2019 2:24 PM, Manu wrote:

 In that callback case, they're effectively anonymously named
 functions...


Yet they are given a name, and extern(C) to get the right calling convention.



 Jul 24 2019



  parent reply Patrick Schluter <Patrick.Schluter bbox.fr>  writes:


On Wednesday, 24 July 2019 at 23:05:33 UTC, Walter Bright wrote:

 On 7/24/2019 2:24 PM, Manu wrote:

 In that callback case, they're effectively anonymously named
 functions...


 Yet they are given a name, and extern(C) to get the right 
 calling convention.


I think the issue here is one of definitions and I think I 
understand why Walter and Manu do not understand each others 
point.

For Manu  extern(?) is mostly about mangling and secondarily 
about calling convention.
For Walter, its first and foremost about calling convention. The 
mangling being unimportant as it can be explicitly set with 
mangle.

When looking at what the specs says [1] it's clear that extern is 
more about calling conventions than mangling

[1]: https://dlang.org/spec/attribute.html#linkage



 Jul 26 2019



 next sibling parent  Patrick Schluter <Patrick.Schluter bbox.fr>  writes:


On Friday, 26 July 2019 at 12:55:10 UTC, Patrick Schluter wrote:

 On Wednesday, 24 July 2019 at 23:05:33 UTC, Walter Bright wrote:

 On 7/24/2019 2:24 PM, Manu wrote:

 In that callback case, they're effectively anonymously named
 functions...


 Yet they are given a name, and extern(C) to get the right 
 calling convention.


 I think the issue here is one of definitions and I think I 
 understand why Walter and Manu do not understand each others 
 point.

 For Manu  extern(?) is mostly about mangling and secondarily 
 about calling convention.
 For Walter, its first and foremost about calling convention. 
 The mangling being unimportant as it can be explicitly set with 
 mangle.

 When looking at what the specs says [1] it's clear that extern 
 is more about calling conventions than mangling

 [1]: https://dlang.org/spec/attribute.html#linkage


To clarify. The issue here is that extern(?) is one keyword 
acting on 2 different things that are only loosely linked: the 
calling convention and the naming convention. What the different 
versions (C, C++, D, Windows, System, Objective-C) actually 
really do is very sketchy and not well defined and can even 
change from platform to platform (C++ mangles differently on 
Windows and Linux afaik).



 Jul 26 2019



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


On Fri, Jul 26, 2019 at 6:00 AM Patrick Schluter via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 July 2019 at 23:05:33 UTC, Walter Bright wrote:

 On 7/24/2019 2:24 PM, Manu wrote:

 In that callback case, they're effectively anonymously named
 functions...


 Yet they are given a name, and extern(C) to get the right
 calling convention.


 I think the issue here is one of definitions and I think I
 understand why Walter and Manu do not understand each others
 point.

 For Manu  extern(?) is mostly about mangling and secondarily
 about calling convention.
 For Walter, its first and foremost about calling convention. The
 mangling being unimportant as it can be explicitly set with
 mangle.

 When looking at what the specs says [1] it's clear that extern is
 more about calling conventions than mangling

 [1]: https://dlang.org/spec/attribute.html#linkage


I'm pretty sure it's about both... you can't separate them and still
be the thing that's written on the tin.
It's highly surprising, and I raise the issue as important having
recently witnessed multiple people being surprised and unimpressed
with this particular quirk. I've talked a lot about tidying up weird
shit that makes bad impressions; I'm getting tired of too many little
things adding up this way, and making it really hard for me to get
colleagues invested and build confidence, this is one such thing.



 Jul 26 2019



  parent reply Ethan <gooberman gmail.com>  writes:


On Friday, 26 July 2019 at 21:34:29 UTC, Manu wrote:

 I'm pretty sure it's about both


100% this.

D can't claim complete 100% C interoperability if it can't 
generate symbols that a C compiler expects to find.

Here's the insane thing about all this, for all those playing at 
home.

Take Manu's example, but add two little "++" symbols. ie:

export extern(C++) void fun() {}

AND

mixin template M()
{
   export extern(C++) void fun() {}
}
mixin M!();

You know what pragma( msg, fun.mangleof ) prints for both of them?

The exact same symbol, of course. _Z3funv on Linux, ?fun  YAXXZ 
on Windows.

What actual legit "this is why this is bad in a production 
environment" reason is there to work as expected for C++ but not 
for C?

--

Manu keeps bringing up getting colleagues using D. It's not 
difficult to find out who he works for. It's not difficult to 
imagine how good it would be for D if D would enter wide usage 
among his colleagues.

Looking through the bug report. "You can get the behaviour you 
wanted with this code hack." No. This *cannot* be the face of the 
D language. Simple stuff like this should Just Work(TM).



 Jul 26 2019



  parent reply Manu <turkeyman gmail.com>  writes:


On Fri, Jul 26, 2019 at 8:10 PM Ethan via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 26 July 2019 at 21:34:29 UTC, Manu wrote:

 I'm pretty sure it's about both


 100% this.

 D can't claim complete 100% C interoperability if it can't
 generate symbols that a C compiler expects to find.


It obviously can, it's just a really weird edge case. The reason is
that it turns out mixin introduces a named scope; something that I
think 99% of people have no idea about, and I'm not sure is helpful.
If mixin doesn't mean mixin, but rather "mix nearby then alias", I
don't find that intuitive.
Every mixin I've ever written, I author it in such a way that if it
were to be used multiple times in the same scope, I handle that if
it's designed to work that way, or I produce an error. I bet everyone
does this?
I also expect that if I wanted to make colliding symbols in the same
scope, I could do that too. I don't love that mixin creates a scope,
it seems weird and pointless and possibly easy to accidentally hide
stuff by mistake... If I wanted a scope, I'd put a scope in my mixin.
I don't believe anyone would expect this.

But in particular, the idea that mangling doesn't work because a
function is in a mixin; that's just too surprising to accept.


 export extern(C++) void fun() {}

 AND

 mixin template M()
 {
    export extern(C++) void fun() {}
 }
 mixin M!();

 You know what pragma( msg, fun.mangleof ) prints for both of them?

 The exact same symbol, of course. _Z3funv on Linux, ?fun  YAXXZ
 on Windows.


Oh really? Serious?
Yeah, this is just a plain straight-up bug. There's no excluse for this.


 Looking through the bug report. "You can get the behaviour you
 wanted with this code hack." No. This *cannot* be the face of the
 D language. Simple stuff like this should Just Work(TM).


Right, you don't move to a shiny new futuristic modern language so you
can start writing weird work-arounds that I can't explain to people on
day-one... it really does make a very bad impression.



 Jul 26 2019



  parent  burjui <bytefu gmail.com>  writes:


So you feel frustrated, having spent so much time arguing with 
Walter and explaining D bugs and "features" to colleagues? Guess 
what, there is a simple solution to your problem, which worked 
wonderfully for me - stop using D.

I wrote a whole rant about D's lack of solid computer science 
foundation, poor management and 20 years of development, but 
decided to not keep it, because it will not affect D development 
anyway and will definitely offend some people. I'll put it this 
way: Andrei's involvement is the best thing that happened to D 
ever, but that is not enough.

Just stop using D and move on. It doesn't really matter if D is 
bad or good or both - as long as you have a dependence problem, 
you are wasting your life, just like I was. There are other 
languages and opportunities out there, go on, explore and have 
fun.



 Jul 28 2019



prev sibling next sibling parent reply Ethan <gooberman gmail.com>  writes:


On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

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

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...


I've only glanced at the thread last night through red eyes.

But on Windows. Because most of my mangling experience is on 
Windows.

If you extern( C ) and it doesn't get mangled to exactly the 
__traits( identifier ) and nothing else then it's being done 
wrong.

You get duplicate symbols? Tough.

I had a similar problem at Remedy with trying to use named 
modules and Binderoo to invoke a commonly named extern( C++ ) 
function. And of course all those functions were mangled exactly 
the same because it's extern( C++ ) and there's no parent 
namespace. I mentioned this in my DConf 2018 talk. My solution is 
outside of the scope of this thread.



 Jul 24 2019



  parent reply Manu <turkeyman gmail.com>  writes:


On Wed, Jul 24, 2019 at 7:20 AM Ethan via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

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

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled
 to
 un-knowable generated names is what any sane user would ever
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...


 I've only glanced at the thread last night through red eyes.

 But on Windows. Because most of my mangling experience is on
 Windows.

 If you extern( C ) and it doesn't get mangled to exactly the
 __traits( identifier ) and nothing else then it's being done
 wrong.

 You get duplicate symbols? Tough.

 I had a similar problem at Remedy with trying to use named
 modules and Binderoo to invoke a commonly named extern( C++ )
 function. And of course all those functions were mangled exactly
 the same because it's extern( C++ ) and there's no parent
 namespace. I mentioned this in my DConf 2018 talk. My solution is
 outside of the scope of this thread.


Yeah, that's not what we're talking about.
Stuff needs to do the right and proper thing, and when that's not what
we want, we need power to override it.

This is a case where extern(C) does weird shit that nobody would ever
expect, and I'm being told to use the override to do the default
thing.
You write `extern(C) void fun();`, you expect a function called "fun",
not "_D9__mixin153funv", why would anyone expect extern(C) to emit a D
function? You can't write that in a `.h` file; the `15` on the end of
"mixin" is a random serial number, it's impossible to know the
function name, you literally can't declare it in a '.h' file!

The rule is "extern(C) might mean what you want, and if it doesn't, we
recommend you use pragma(mangle) to reconstruct the C symbol name...
but don't forget to check if you need an underscore!"



 Jul 24 2019



  parent  Ethan <gooberman gmail.com>  writes:


On Wednesday, 24 July 2019 at 21:32:11 UTC, Manu wrote:

 You write `extern(C) void fun();`, you expect a function called 
 "fun",
 not "_D9__mixin153funv"


Yes, that's what I expect. The similar problem I had with 
extern(C++) was that I should have expected it. extern(C++) works 
as expected but extern(C) doesn't? Strange things are afoot at 
the Circle K...


 The rule is "extern(C) might mean what you want, and if it 
 doesn't, we
 recommend you use pragma(mangle) to reconstruct the C symbol 
 name...
 but don't forget to check if you need an underscore!"


And this is what Binderoo is doing. In a roundabout way, that is. 
Defining extern(C) and extern(C++) everywhere gets in the way of 
just writing D code, so Binderoo generates C and C++ wrappers. 
Bonus with this approach: inlining is preserved.

(Got some almost-finished code to correctly make C++ mangles for 
templated types, works for basically everything else so static 
linking should Just Work(TM) ).



 Jul 24 2019



prev sibling  parent  Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com>  writes:


On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:

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

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...


This has got to be one of the most duplicated issues in bugzilla. 
It's in there as 962 (12 years ago!), 4581, 6132, 7005, 12575, 
15712, 15843, 17748, and now as 20012. There may even be more.

As evinced by 4581 (which I filed in 2013), I'm on your side 
here. I also like Mike Franklin's idea of pragma(mangle, D) to 
handle the other cases.

--
   Simen



 Jul 25 2019