David Nadlinger via Digitalmars-d
digitalmars-d at puremagic.com
Wed Jan 20 16:43:13 PST 2016
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
> 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
We like our D modules as they are , 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
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 .
 That is, except for issue 314 and the visibility vs.
 Those scopes might of course currently leak into the C++
mangled name – I didn't check –, but this can be fixed.
More information about the Digitalmars-d