On 17/01/2016 6:09 AM, Walter Bright wrote:
On 1/16/2016 6:26 AM, Daniel Murphy wrote:
Nobody
wants conflicting symbols in a module, and nobody wants to cram all of
their C++
namespace bindings inside a single D source file to avoid getting
namespace
symbol conflicts.
D's namespace system does not suffer from those faults.
Sure it does. Here's the situation:
I have two C++ headers in a library:
library\a.h:
namespace "mylib"
{
void funca() { ... }
}
library\b.h:
namespace "mylib"
{
void funcb() { ... }
}
I want to create D bindings and keep a similar import layout. So I make:
module library.a;
extern(C++, mylib) void funca();
and
module library.b;
extern(C++, mylib) void funcb();
And now I have two library namespace symbols I never wanted. I just
wanted to mangle the same as the C++ symbols. D's module system already
takes care of resolving conflicts.
So now we have two public symbols called 'mylib', and because they
conflict they can't be used to disambiguate eg 'someotherlib.funca' with
'library.a.funca'.
The only advantage of the current system I've seen presented is that you
can now have multiple conflicting symbols in the same module. I can see
how that's useful in C++, but I don't think it helps _binding_ to C++ at
all. Or how it's worth the mess the extra symbols cause.
