On Friday, 14 September 2018 at 13:10:07 UTC, Atila Neves wrote:
> On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
>> [...]
>
> I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does.
>
> Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link.
>
> Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends.
>
> Forum chatter won't do it though, we need a DIP.
Someone is already on it.
https://github.com/look-at-me/DIPs/blob/please-for-the-love-of-all-things-good-and-holy-fix-cpp-mangling-please-ok-sorry/DIPs/DIPxCPP.md

On Fri, 14 Sep 2018 at 07:55, 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Friday, 14 September 2018 at 13:10:07 UTC, Atila Neves wrote:
> > On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
> >> [...]
> >
> > I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does.
> >
> > Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link.
> >
> > Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends.
> >
> > Forum chatter won't do it though, we need a DIP.
> Someone is already on it. https://github.com/look-at-me/DIPs/blob/please-for-the-love-of-all-things-good-and-holy-fix-cpp-mangling-please-ok-sorry/DIPs/DIPxCPP.md

I can't wait for a DIP.
That's like 12 months turnaround, and I've already lost weeks waiting
for some trivial PR's about version identifiers that are still
pending... this will take years.

On Friday, September 14, 2018 10:56:45 AM MDT Manu via Digitalmars-d wrote:
> On Fri, 14 Sep 2018 at 07:55, 12345swordy via Digitalmars-d
>
> <digitalmars-d@puremagic.com> wrote:
> > On Friday, 14 September 2018 at 13:10:07 UTC, Atila Neves wrote:
> > > On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
> > >> [...]
> > >
> > > I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does.
> > >
> > > Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link.
> > >
> > > Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends.
> > >
> > > Forum chatter won't do it though, we need a DIP.
> >
> > Someone is already on it. https://github.com/look-at-me/DIPs/blob/please-for-the-love-of-all-thing s-good-and-holy-fix-cpp-mangling-please-ok-sorry/DIPs/DIPxCPP.md
> I can't wait for a DIP.
> That's like 12 months turnaround, and I've already lost weeks waiting
> for some trivial PR's about version identifiers that are still
> pending... this will take years.

Per the current procedure, it pretty much has to be done via a DIP. It might be possible for it to be fast-tracked, but without Walter and/or Andrei being behind it from the get-go, the chances of that happening aren't good. Really, the only way that this could go quickly would be if Walter and/or Andrei were somehow convinced that extern(C++, NS) was completely broken and that it was critical that it be fixed ASAP. And clearly, Walter is going to be very hard to convince (though maybe we'll get lucky and Andrei will be easy to convince - I have no clue what his position on the issue is). The only real leverage here is likely that they think that C++ integration is important. However, as long as Walter thinks that what we have should work just fine, he's not about to rush to change it.

Regardless, given Walter's position on the situation, we pretty much have to have a DIP if nothing else so that we have a clear, well-written document to present to him. Arguing about it in the newsgroup clearly isn't getting us anywhere. After a solid DIP is written, then _maybe_ we could find a way to expedite things, but I think that he's already made it pretty clear that if we want any chance of change, we need a DIP.

And while the DIP process might be annoyingly slow, if we don't get a DIP in the queue, I think that it's pretty clear that nothing will change unless Walter or Andrei does something significant with extern(C++, NS) and gets really annoyed at how bad it is (which seems to be how Andrei usually gets fired up on fixing something that other people had been insisting needed to be changed, but he'd thought was fine).

- Jonathan M Davis

On Fri, Sep 14, 2018, 08:47 Manu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thu, 13 Sep 2018 at 04:46, Danni Coy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
> >>
> >> The entire point of having extern(C++, "NS") would be to make it so
> that the
> >> _only_ thing that it would affect would be the name mangling. Everything else is exactly the same behavior as it would be if you had the same functions as extern(D). It would be up to the programmer to organize
> them
> >> exactly like it is with pure D code. If you think that putting two
> functions
> >> in the same module is too risky, then you can put them in separate
> modules,
> >> but it certainly isn't going to be forced on you unless they actually conflict. The fact that functions are extern(C++) would have no impact
> on
> >> that whatsoever.
> >
> > Yeah I get all this. It just seems to me that the downsides of
> extern(C++,"ns") from Walter's point of view could be handled by the compiler at the cost of a bit of flexibility.
>
> What are the 'downsides' you refer to? And what 'flexibility' is lost? The whole point is to gain flexibility. There's definitely no loss of flexibility on the table here ;)
>
> > I would like to know how difficult that would be to do and whether that
> would be more acceptable to Walter than what is being being proposed.
>
> You'll need to elaborate. What is being proposed is the simplest possible, most plainly obvious, let's-not-introduce-unwieldy-edge-cases solution.
>
> Walters named scope should be an unrelated and parallel feature if he really wants it.
>

You are suggesting extern(c++,"ns") be a parallel feature to extern(c++,ns). I am asking how difficult technically would it be to have your syntax replace Walters but have the compiler check for the situations where a function from one C++ namespace might shadow one in a different namespace and emit either a warning or an error.

Honestly I just want to know if going that path will have more or less friction from Walter.

>

On Fri, Sep 14, 2018, 06:01 Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, September 13, 2018 5:45:56 AM MDT Danni Coy via Digitalmars-d wrote:
> > On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <
> >
> > digitalmars-d@puremagic.com> wrote:
> > > The entire point of having extern(C++, "NS") would be to make it so
> that
> > > the
> > > _only_ thing that it would affect would be the name mangling.
> Everything
> > > else is exactly the same behavior as it would be if you had the same
> > > functions as extern(D). It would be up to the programmer to organize
> > > them
> > > exactly like it is with pure D code. If you think that putting two
> > > functions
> > > in the same module is too risky, then you can put them in separate
> > > modules, but it certainly isn't going to be forced on you unless they
> > > actually conflict. The fact that functions are extern(C++) would have
> > > no impact on that whatsoever.
> >
> > Yeah I get all this. It just seems to me that the downsides of
> > extern(C++,"ns") from Walter's point of view could be handled by the
> > compiler at the cost of a bit of flexibility.
> > I would like to know how difficult that would be to do and whether that
> > would be more acceptable to Walter than what is being being proposed.
>
> I don't know what Walter would go for, but trying to do anything special
> for
> extern(C++, "NS") symbols pretty much defeats the whole purpose of using
> extern(C++, "NS") over extern(C++, NS). And the issue that you are trying
> to
> find a way to prevent is something that D code in general has to worry
> about, so I don't think that it makes any sense to try to treat extern(C++)
> symbols as special to try to fix it.
>
> If we have extern(C++, "NS"), then anyone creating C++ bindings will have
> to
> worry about conflicts in exactly the same way that they would with D code.
> You have to do that with extern(C++, NS) too. It's that it's then only with
> the functions within that namespace.
>
> Walter's concerns seem to center around the idea that we somehow need to
> model C++ namespaces in D, so that's really what needs to be addressed
> somehow. The D module system gives us everything we need to lay out symbols
> so that they don't conflict. The only thing that it can't do is allow you
> to
> put conflicting symbols in the same module, making it harder to have a
> 1-to-1 correspondance between D modules and C++ header files in rare cases,
> but all we need to do to solve that is to either leave in extern(C++, NS)
> for those cases or to make it so that something like
>
> static NS1
> {
>     extern(C++, "NS1") static void foo(int bar);
> }
>
> static NS2
> {
>     extern(C++, "NS2") static void foo(int bar);
> }
>
> works (which is basically what extern(C++, NS) is doing anyway). But honestly, in most cases, it just makes more sense to split up the symbols between modules, and in the vast majority of cases, you simply don't have multiple namespaces with conflicting symbols in the same header file.
>
> - Jonathan M Davis
>

So extern(C++,"ns") replaces the existing syntax and then improve D's general ability to hand functioning hijacking other functions would be the best solution and Walters modelling of namespaces is fixing the problem in the wrong place?

>

On Saturday, 15 September 2018 at 00:07:44 UTC, Danni Coy wrote:
> So extern(C++,"ns") replaces the existing syntax

It would be in addition, at least at first. The current syntax might be deprecated.

> and then improve D's general ability to hand functioning hijacking other functions would be the best solution

D already has tools for this.

> and Walters modelling of namespaces is fixing the problem in the wrong place?

The current solution solves the very uncommon problem of having two different namespaces in the same file, containing symbols with the same names (or, if functions, with common overloads), where the person writing the bindings needs to keep a one-to-one correspondence between C++ headers and D files, and they don't want to introduce any meaningless structs or templates.

Specifically, Walter wants this to compile:

module whatever;
extern(C++, foo) void doStuff();
extern(C++, bar) void doStuff();

And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like:

import core.stdcpp.sstream;
import core.stdcpp.vector;
core.stdcpp.vector.std.vector v;

On 9/14/18 6:41 PM, Neia Neutuladh wrote:

> Specifically, Walter wants this to compile:
> 
> module whatever;
> extern(C++, foo) void doStuff();
> extern(C++, bar) void doStuff();
> 
> And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like:
> 
> import core.stdcpp.sstream;
> import core.stdcpp.vector;
> core.stdcpp.vector.std.vector v;

This is probably the best explanation of why the current situation sucks.

-Steve

On Sunday, 16 September 2018 at 17:46:26 UTC, Steven Schveighoffer wrote:
> On 9/14/18 6:41 PM, Neia Neutuladh wrote:
>
>> Specifically, Walter wants this to compile:
>> 
>> module whatever;
>> extern(C++, foo) void doStuff();
>> extern(C++, bar) void doStuff();
>> 
>> And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like:
>> 
>> import core.stdcpp.sstream;
>> import core.stdcpp.vector;
>> core.stdcpp.vector.std.vector v;
>
> This is probably the best explanation of why the current situation sucks.
>
> -Steve

Agreed. Up until now, I didn't even understand the rationale for why it works the way it does.

On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 16 September 2018 at 17:46:26 UTC, Steven Schveighoffer wrote:
> > On 9/14/18 6:41 PM, Neia Neutuladh wrote:
> >
> >> Specifically, Walter wants this to compile:
> >>
> >> module whatever;
> >> extern(C++, foo) void doStuff();
> >> extern(C++, bar) void doStuff();
> >>
> >> And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like:
> >>
> >> import core.stdcpp.sstream;
> >> import core.stdcpp.vector;
> >> core.stdcpp.vector.std.vector v;
> >
> > This is probably the best explanation of why the current situation sucks.
> >
> > -Steve
>
> Agreed. Up until now, I didn't even understand the rationale for why it works the way it does.

https://github.com/dlang/dmd/pull/8667

O_O

Thank you Walter for coming to the party!

On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote:
> On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d
>
> <digitalmars-d@puremagic.com> wrote:
> > On Sunday, 16 September 2018 at 17:46:26 UTC, Steven
> >
> > Schveighoffer wrote:
> > > On 9/14/18 6:41 PM, Neia Neutuladh wrote:
> > >> Specifically, Walter wants this to compile:
> > >>
> > >> module whatever;
> > >> extern(C++, foo) void doStuff();
> > >> extern(C++, bar) void doStuff();
> > >>
> > >> And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like:
> > >>
> > >> import core.stdcpp.sstream;
> > >> import core.stdcpp.vector;
> > >> core.stdcpp.vector.std.vector v;
> > >
> > > This is probably the best explanation of why the current situation sucks.
> > >
> > > -Steve
> >
> > Agreed. Up until now, I didn't even understand the rationale for why it works the way it does.
>
> https://github.com/dlang/dmd/pull/8667
>
> O_O
>
> Thank you Walter for coming to the party!

Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty clear that a DIP was needed, and even then, it didn't seem likely that it would be accepted. This is awesome. I guess that he finally came around.

- Jonathan M Davis