<p dir="ltr">On 29 Nov 2015 6:17 am, "Manu via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On 29 November 2015 at 14:57, Walter Bright via Digitalmars-d<br>
> <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
> ><br>
> > D does not support C++ semantics. You cannot split namespaces into multiple<br>
> > files in D, nor can you add symbols to an existing namespace. For namespace<br>
> > NS, all the declarations in NS have to be in one file and between the { },<br>
> > just like any other scope in D.<br>
><br>
> Then the feature fails. You can't put the entire STL in one file.<br>
> C++ doesn't namespace per file, it generally namespaces per project...<br>
> so this is the common case; every module define symbols in the same<br>
> C++ namespace.<br>
><br>
></p>
<p dir="ltr">This (and response below about mangling) answers a recent question in a PR I made.  I had noticed the same when writing a testsuite case, only to discover you can only declare `extern(C++, std)` once.  For me, having all related code for a test close together is a nice-to-have though.</p>
<p dir="ltr">> >> Additionally to that, I don't really want the C++ namespaces to be<br>
> >> visible to D; they should be for mangling purposes only.<br>
> ><br>
> ><br>
> > We considered making them for mangling only, and rejected it as unworkable,<br>
> > because then two identical names in different namespaces could not be<br>
> > distinguished by the D symbol table system.<br>
><br>
> I understand, and that's fine, but it's not particularly useful unless<br>
> I can make the namespace invisible and alias the namespaced symbols<br>
> into D's module (user-accessible) scope. Otherwise importing 2 modules<br>
> leads to conflicting namespace and symbol resolution is all messed up.<br>
></p>
<p dir="ltr">Renamed imports should work here?</p>
<p dir="ltr">><br>
> >> So I try code like this:<br>
> >>    private extern(C++, NS) struct Thing {}<br>
> >>    alias Thing = NS.Thing;<br>
> >><br>
> >> The idea being that NS will not be available externally, and they<br>
> >> should use Thing in module scope instead, but that doesnt work with<br>
> >> errors:<br>
> >>    Error: module blah class blah.NS.Thing is private<br>
> >><br>
> >> It seems aliasing a private thing into the public namespace does not<br>
> >> make it accessible via that alias?<br>
> ><br>
> ><br>
> > Aliases do not change access permissions. They are just aliases.<br>
><br>
> Maybe a special case for C++ namespaces? Or some other solution that<br>
> produces the same result.<br>
> It's a weird sort of permission this one, it's not that the symbols<br>
> are 'private'; I intend the user to use them, I just want the C++<br>
> hierarchy excluded from the symbol table and only accessibly by<br>
> controlled/explicit alias.<br>
></p>
<p dir="ltr">You may have already noticed, but `extern(C++, NS)` behaves more like importing a module, but rather than the module being in a separate file, it's contents are put inplace of the braces.</p>
<p dir="ltr">Like importing modules in D, the namespace name itself is not a strong encapsulation (unlike e.g D enums), so whether you use Thing or NS.Thing, both will resolve to the same symbol.  The same should also be true when importing a namespace from another module.</p>
<p dir="ltr">I think your idea with aliases was just wishful thinking, aliases themselves never worked like that.</p>