extern(C++, ns) is wrong

[Jonathan M Davis]

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 at 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