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).

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.

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.