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

[Jonathan M Davis]

On Sunday, July 29, 2018 6:10:01 AM MDT kinke via Digitalmars-d wrote:
> On Sunday, 29 July 2018 at 11:03:43 UTC, Jonathan M Davis wrote:
> > I guess that the argument at that point is that you would have
> > to put them in separate D modules, just like you would if they
> > were extern(D) functions.
>
> Yep, that'd sound acceptable to me, implying that
>
> ```
> extern(C++, cppns) { void foo(); }
> void foo();
> ```
>
> wouldn't work anymore, and particularly, this neither:
>
> ```
> extern(C++, cppns)
> {
>      extern(C++, nested) { void foo(); }
>      void foo();
> }
> ```
>
> so that a straight C++ namespace => D module hierarchy mapping
> would probably be required in the general case:
>
> ```
> // cppns/package.d
> module cppns;
> extern(C++, cppns) { void foo(); }
>
> // cppns/nested/package.d
> module cppns.nested;
> extern(C++, cppns) extern(C++, nested) { void foo(); }
> ```

Honestly, I'd expecting folks doing bindings for anything serious would be
matching the layout of the C++ header files being translated. It becomes
difficult to maintain bindings when their layout doesn't match the original
files. Most of druntime's C bindings match the layout of the C headers that
they're translating so that it's straightforward to find them (the primary
exception being that OS-specific symbols from a standard header end up in a
different file, which can be confusing and maybe shouldn't have been done,
but those files follow the same layout - just in a different hierarchy under
the OS's name). Anyone who didn't at least nominally make the layouts match
would almost certainly run into maintenance problems in the long run.

- Jonathan M Davis