On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to
mangle symbols.
Namespaces have semantic implications, too, such as overload
resolutions. A namespace introduces a new scope, not just a
mangling.
> But why does this not compile?
> extern(C++, ns) { void foo(); }
> extern(C++, ns) { void bar(); }
For the same reason that:
struct ns { void foo(); }
struct ns { void bar(); }
doesn't. Being able to crack open a scope and stuff more
symbols into it at any point in a program is just madness :-)
However, one can do:
------ module A ---------
extern(C++, ns) { void foo(); }
------ module B ---------
extern(C++, ns) { void bar(); }
------ module C ---------
import A,B;
ns.foo(); // error, A.ns or B.ns?
A.ns.foo(); // ok
Because the compiler sees A.ns as utterly distinct from B.ns,
although the mangling will be the same - any conflicts will be
the linker's problem.
This is how, for example, extern(C) declarations can exist in
many files.
> Such a program can easily do that to `extern(C)`, but doing
that to `extern(C++)` is for some reason not allowed.
It is allowed. Just not reopening the same namespace.
Namespaces are a botch in C++, and it is understandable that
C++ code bases naturally have grown willy-nilly to utterly
ignore any encapsulation principles. It's analogous to how
monkey-patching in Ruby was seen initially as a cool feature,
but eventually people learned the hard way what a disastrous
idea it was.
Thanks for the explanation, Walter.
Can you think of a pragmatic solution to Atila's problem?
Because it's getting in the way of a decent prize - to be able
just to #include CPP headers and link with C++. Obviously some
work elsewhere still to do, but translation of headers is worth
quite a lot if you are a commercial user and don't have much time
to write a first exploratory version.
Already just having #include work for a lot of C libraries makes
an immense difference.
D "doesn't have libraries". Well there's some good stuff on
code.dlang.org plus every C library - a few of those, so I hear.
And with C++ on top it starts to become about as persuasive as
"there are no good jobs in D". (Reminder - we are hiring and we
pay well).
