Is there any good reason why C++ namespaces are "closed" in D?

[Rubn]

On Tuesday, 31 July 2018 at 16:23:55 UTC, Manu wrote:
> On Tue., 31 Jul. 2018, 3:40 am Jacob Carlborg via 
> Digitalmars-d, < digitalmars-d at puremagic.com> wrote:
>
>> On 2018-07-31 10:12, Manu wrote:
>>
>> > Given your favourite example:
>> > ----
>> > module a;
>> > extern(C++, ns) void foo();
>> > ----
>> > module b;
>> > extern(C++, ns) void foo();
>> > -----
>> > module c;
>> > import a, b;
>> > foo(); // error: ambiguous
>> > ns.foo(); // error, ambiguous (obviously)
>> > a.ns.foo(); // naturally, this works... it's the D module 
>> > that
>> > correctly organises the symbol. 'ns' is worthless here
>>
>> This works:
>>
>> a.foo();
>>
>> You don't need "ns" in between the module name and the 
>> function.
>>
>
> Right... But did you miss the point? The D module does the 
> organisation (as
> you show). The ns offers nothing and creates other kinds of 
> problems.
> Just because name resolution traverses the namespace (in simple 
> cases),
> there is an entire language of complexity that interacts with 
> that name
> lookup, and as far as I know, it has never proven useful, but 
> rather, only
> complicated and annoying leading to boilerplate and hacks in 
> certain
> situations. (ie, this thread exists and many others)

Can you give some examples of those certain situations? It would 
help clear what is wrong with how it is currently implemented.


One thing I don't like is that the C++ namespaces takes the name. 
So if you try to import a module that has C++ namespace of the 
same with the existing module, then you'll get an error. For 
effectively no reason, because as you say that namespace is 
useless and just occupies a name that could otherwise be used for 
the module name.