extern(C++, NS)

[Walter Bright via Digitalmars-d]

On 11/28/2015 8:40 PM, Manu via Digitalmars-d wrote:
> I'm having a lot of trouble with C++ namespaces.
> The problem is, the namespace is not just attributed to the symbol in
> D, but it's emulated as a named scope.

It is not "emulated" in D, it is an actual named scope in D.


> The trouble mostly appears in this situation:
>
> file1.d
>    extern(C++, NS) struct X;
>
> file2.d
>    extern(C++, NS) struct Y;
>
> file3.d
>    import file1, file2;
>    X x; // nope
>    Y y; // nope
>    NS.X x; // NS has multiple definitions...
>    NS.Y y; // NS has multiple definitions...
>
>
> And various other configurations similar to this where multiple files
> declare symbols in the same C++ namespace, and then something tries to
> import more than one of them.
> Circular imports of this sort always cause problems.

D does not support C++ semantics. You cannot split namespaces into multiple 
files in D, nor can you add symbols to an existing namespace. For namespace NS, 
all the declarations in NS have to be in one file and between the { }, just like 
any other scope in D.


> Additionally to that, I don't really want the C++ namespaces to be
> visible to D; they should be for mangling purposes only.

We considered making them for mangling only, and rejected it as unworkable, 
because then two identical names in different namespaces could not be 
distinguished by the D symbol table system.


> So I try code like this:
>    private extern(C++, NS) struct Thing {}
>    alias Thing = NS.Thing;
>
> The idea being that NS will not be available externally, and they
> should use Thing in module scope instead, but that doesnt work with
> errors:
>    Error: module blah class blah.NS.Thing is private
>
> It seems aliasing a private thing into the public namespace does not
> make it accessible via that alias?

Aliases do not change access permissions. They are just aliases.


> The only way I've managed to make any of those work is with proxy
> modules, which static import the C++ module, and then `alias Thing =
> NS.Thing` into the proxy module's scope. This is horrid, and it
> doubles my module count. I haven't found another pattern that's
> reliably workable.
>
> Ideas?

Stop trying to bash D into behaving like C++! It'll just make for horrid code 
(as you discovered) and make you miserable trying. D has an interface to C++; it 
does not have C++ semantics.