extern(C++, NS)

[Iain Buclaw via Digitalmars-d]

On 29 Nov 2015 6:17 am, "Manu via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On 29 November 2015 at 14:57, Walter Bright via Digitalmars-d
> <digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20151129/95256e6b/attachment.html>