extern(C++, ns)

[David Nadlinger via Digitalmars-d]

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.