extern(C++, ns)

[Rikki Cattermole via Digitalmars-d]

On 03/01/16 5:54 PM, Manu via Digitalmars-d wrote:
> C++ namespacing is causing me endless, and I mean *endless* trouble.
> This idea that we express the C++ namespace hierarchy in D is the main
> problem.
> I don't think C++ namespaces should interfere with D scoping rules, they
> should be purely for mangling.
> It creates a whole bundle of edge cases which either don't have work
> arounds, or REALLY awkward workarounds which typically have a heavy
> impact on all the regular D code that the C++ code interacts with.
>
> Not least of which is that C++ namespaces usually span the entire
> project, and in D a C++ namespace can only appear in one module ever.
> Declaring symbols with the same C++ namespace in different modules leads
> to multiple definition errors, and if you are super-careful to avoid
> those, you gain name resolution issues in it's place.
>
> It is also very awkward that a C++ namespace can't be the same as a top
> level package name. My top level package is named the same as one of my
> C++ namespaces... what do I do? It gets ugly real fast.
>
> The main problem extends from this situation:
>
> module x.y;
>
> extern(C++, ns) struct Y {}
>
>
> module ns.m;
>
> import x.y; // fail, the c++ namespace is already present (top level module)
> import x.y : ns.Y; // fail, '.' can't appear here
> import x.y : Y; // fail, not found
>
> // This **sometimes** works, and it's very brittle
> static import x.y;
> alias Y = x.y.Y;
>
>
> Thing is, I'm not declaring a C++ object, I'm declaring a D object, the
> only thing being that struct's take care to maintain common binary
> layout, and functions just mangle like C++ so that my code links. I'm in
> D, I'm declaring my stuff in the D module where it should be scoped, and
> where other D code should expect to find it. I don't see any point in
> building the C++ hierarchy in this space. C++ namespace rules are
> incompatible with D; you can litter them through C++ code, and add new
> symbols to C++ namespaces from anywhere... this is fundamentally
> incompatible with D, and no further reasoning should be required to
> conclude that it can't be reproduced, so it should be for mangling
> purposes only.
>
> I have spent **days**, actually, weeks of my free time trying to make my
> tiny bit of code build, and it's just nothing but trouble after trouble.
> I have completely restructured my code at least 3 times to try and find
> a way to make it fit together in a way that's both practical and works,
> but I just can't. It always hits some brick wall somewhere.
>
> extern(C++, NS) looks okay in isolated tests/experiments, but try and
> actually use it, and you will become very frustrated.
>
> Please, fix this. I'm almost done. I'm really struggling to keep this
> dream alive.

Ok, so what I gathered from that is that if a D package/module matches a 
C++ one in scope, D will only be checked.
The obvious answer would be to rename the D side, but that really isn't 
good enough.

Since I'm in no position to help, well this is a bit useless comment.