extern(C++, ns)

[Carl Sturtivant via Digitalmars-d]

OK, I'm going to state the obvious here in the hope it will be 
considered afresh. :)

On Sunday, 3 January 2016 at 17:53:38 UTC, Walter Bright wrote:
> 5. I don't share the opinion that a C++ namespace introducing a 
> scope, just as it does in C++, is something weird and 
> unexpected.

Wait a second: D has modules with clever import rules and no 
global scope to manage name collisions instead of namespaces. See 
the bullet here under "features to drop from C++":
http://dlang.org/overview.html#features_to_drop

What's now going on is the reintroduction of this dropped feature 
in a way that is at cross purposes to the underlying D language 
philosophy.

In the end the disputed difficult comes down to this:
     extern(C++, ns1) int fn(int x);
and
     extern(C++, ns2) int fn(int x);
have different mangled names but the same D-source name. They 
also have the same C++ source name.

In the C++ source this collision is averted by namespaces. In the 
D source where the namespace mechanism has been designed out in 
favor of the module mechanism, this collision should be averted 
using the module mechanism.

If you still believe you want to be able to place the colliding 
externals in the same module, i.e. not use D's collision 
avoidance mechanism, what's needed is simply the ability to have 
two different D source names for the two functions specified in 
the two declarations. This is just a name change, not an entire 
new scope with all the complexity that would entail in the 
namespace situation.

Perhaps there's a way to do this in D already: how do you link to 
a C function whose name is 'new' or some other D keyword?

In any case, drawing a distinction between the D source name and 
the C++ source name (or the external source name in general) in 
the external declaration would do the job. e.g.

extern(C++, ns1, fn) int fn1(int x);
extern(C++, ns2, fn) int fn2(int x);

In each case the external declaration has enough information to 
compute the mangled name and attach it to a D source name without 
collision.

My opinion: Injecting C++ bad design into D in the name of 
linkage is wrong, ugly, and over complicated. I don't think the 
alternative mechanism suggested in the preceding paragraph or 
anything similar is necessary either, since D modules are the 
replacement for namespaces in going from C++ to D, and they can 
do the job. But something like that alternative is a lot less 
awful.