On 29 Nov 2015 6:17 am, "Manu via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On 29 November 2015 at 14:57, Walter Bright via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: > > > > 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. > > Then the feature fails. You can't put the entire STL in one file. > C++ doesn't namespace per file, it generally namespaces per project... > so this is the common case; every module define symbols in the same > C++ namespace. > >
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. > >> 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. > > I understand, and that's fine, but it's not particularly useful unless > I can make the namespace invisible and alias the namespaced symbols > into D's module (user-accessible) scope. Otherwise importing 2 modules > leads to conflicting namespace and symbol resolution is all messed up. > Renamed imports should work here? > > >> 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. > > Maybe a special case for C++ namespaces? Or some other solution that > produces the same result. > It's a weird sort of permission this one, it's not that the symbols > are 'private'; I intend the user to use them, I just want the C++ > hierarchy excluded from the symbol table and only accessibly by > controlled/explicit alias. > 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. 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. I think your idea with aliases was just wishful thinking, aliases themselves never worked like that.