July 24, 2019
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.

July 24, 2019
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.
July 24, 2019
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.
July 24, 2019
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.
July 24, 2019
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!"
July 24, 2019
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) ).
July 24, 2019
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
July 24, 2019
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.
July 24, 2019
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é!
July 25, 2019
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).