Is there any good reason why C++ namespaces are "closed" in D?

[Laeeth Isharc]

On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
> On 7/27/2018 10:28 AM, Atila Neves wrote:
>> But all I'm trying to do here is tell the D compiler how to 
>> mangle symbols.
>
> Namespaces have semantic implications, too, such as overload 
> resolutions. A namespace introduces a new scope, not just a 
> mangling.
>
> > But why does this not compile?
> > extern(C++, ns) { void foo(); }
> > extern(C++, ns) { void bar(); }
>
> For the same reason that:
>
>     struct ns { void foo(); }
>     struct ns { void bar(); }
>
> doesn't. Being able to crack open a scope and stuff more 
> symbols into it at any point in a program is just madness :-)
>
> However, one can do:
>
> ------ module A ---------
>     extern(C++, ns) { void foo(); }
>
> ------ module B ---------
>     extern(C++, ns) { void bar(); }
>
> ------ module C ---------
>     import A,B;
>     ns.foo(); // error, A.ns or B.ns?
>     A.ns.foo(); // ok
>
> Because the compiler sees A.ns as utterly distinct from B.ns, 
> although the mangling will be the same - any conflicts will be 
> the linker's problem.
>
> This is how, for example, extern(C) declarations can exist in 
> many files.
>
> > Such a program can easily do that to `extern(C)`, but doing
> that to `extern(C++)` is for some reason not allowed.
>
> It is allowed. Just not reopening the same namespace.
>
> Namespaces are a botch in C++, and it is understandable that 
> C++ code bases naturally have grown willy-nilly to utterly 
> ignore any encapsulation principles. It's analogous to how 
> monkey-patching in Ruby was seen initially as a cool feature, 
> but eventually people learned the hard way what a disastrous 
> idea it was.

Thanks for the explanation, Walter.

Can you think of a pragmatic solution to Atila's problem?

Because it's getting in the way of a decent prize - to be able 
just to #include CPP headers and link with C++.  Obviously some 
work elsewhere still to do, but translation of headers is worth 
quite a lot if you are a commercial user and don't have much time 
to write a first exploratory version.

Already just having #include work for a lot of C libraries makes 
an immense difference.

D "doesn't have libraries".  Well there's some good stuff on 
code.dlang.org plus every C library - a few of those, so I hear.  
And with C++ on top it starts to become about as persuasive as 
"there are no good jobs in D".  (Reminder - we are hiring and we 
pay well).