On Tuesday, 19 January 2016 at 22:14:42 UTC, Walter Bright wrote:
1. C++ has namespaces. They went and invented a whole 'nother
thing called modules. Evidently not even they think that
modules and namespaces are the same thing.
C++ modules (as per N4465, etc.) are a whole different story and
entirely unrelated to the discussion. Their existence is neither
an argument for or against having extern(C++) create named scopes
for namespaces.
2. Multiple modules cannot have the same name in D. C++
practice is to litter code with namespaces using the same name.
If you want to split up the interface to a C++ namespace among
different modules, then the different symbols will *always*
reside in different fully qualified scopes – with or without
additional scopes being introduced by extern(C++)! The fact that
modules are "sealed" scopes is an integral part of the D module
system, and while your statement is true, I'm not sure how it
constitutes an argument for having extern(C++) introduce more
scopes in addition to that.
3. Modules have ModuleInfos, static constructors/destructors,
etc. These do not make obvious sense for namespaces.
How does this apply to the discussion? Again, extern(C++) code
lives inside a D module either way.
[…]
Actually, I'll skip commenting on the other points for now,
because reading your last paragraph makes me suspect that there
is a misunderstanding:
I.e. if modules were bludgeoned into being namespaces, there
would be such a list of special cases and confusions and
exceptions and awkward crap you'd be far, far better off having
namespace as a SEPARATE feature, because that's what they'd
wind up being anyway, even if they were named "modules".
From this statement, it seems as if you think we are arguing for
modules somehow being mapped directly to C++ namespaces, in the
vein of some hypothetical "module(C++, ns) foo;" declaration.
However, this is not the case at all. Quite the contrary, my
proposal (and, as far as I understand also that of Manu, Daniel
and others who have agued against your design) is that C++
namespaces should have no semantic representation on the D side
at all.
We like our D modules as they are [1], and we are certainly not
trying to bludgeon them into any other shape. Given the vast
semantical differences between them and C++ namespaces – and you
haven't even really mentioned the extensibility aspect and the
new inline namespaces in your list – this would be a foolish
thing to do.
Modules only enter the picture in so far as they provide a
natural way for client code of two C++ library wrappers to
disambiguate between two symbols that have the same name, as it
might happen if they correspond to C++ symbols from different
namespaces.
In other words, modules would likely quite often happen to
provide the necessary means of disambiguation, because one would
put the wrappers for two different C++ namespaces into different
D modules anyway. But if you wanted to have, say, two
declarations for interfacing with both A::foo() and B::foo()
within the same D module, you could always use another of D's
scoping mechanism for that, like (mixin) templates or whatever
else tickles your fancy [2].
— David
[1] That is, except for issue 314 and the visibility vs.
accessibility problem.
[2] Those scopes might of course currently leak into the C++
mangled name – I didn't check –, but this can be fixed.
