On 1/2/2016 8: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.
That works the same as in C++. Don't define the same symbol in the same C++
namespace in multiple modules. It doesn't work in C++, and doesn't work in D for
exactly the same reason.
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)
Doesn't fail when I try it.
import x.y : ns.Y; // fail, '.' can't appear here
Right, this syntax only works for module scope declarations. Y is not module
scope.
You can do:
import x.y : ns;
import x.y : Y; // fail, not found
Again, Y is not module scope.
// This **sometimes** works,
sometimes?
and it's very brittle
??
static import x.y;
alias Y = x.y.Y;
Nothing wrong with that.
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...
You can do that in D as well, as long as you follow the One Definition Rule,
which you have to with C++ code anyway.
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 guarantee you that if we'd implemented it that way, you'd have a long litany
of complaints about that, because the compiler could not distinguish Y from ns.Y.
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.
I do not understand what difficulty you are having with this.
