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

[Walter Bright]

On 8/2/2018 2:26 AM, Daniel N wrote:
> Personally I would never *bind* to two different namespaces in a single file, 

You'd be amazed at what people do and then set their entire store based on it. 
If the language spec allows it, people will do it. People will even design their 
code to require certain bugs in the compiler. (This really blows when you're 
trying to write a standard compliant C/C++ compiler and you get angry letters 
from customers about why I'm not supporting some stupid bug in BrandX C++ that 
they rely on.)

One of my favorite stories about this was a company that had a coding style 
where their comments looked like this:

     //******** text ********\\

     int x;

They thought it was marvelous! But what really happens when you've got two line 
concatenation characters at the end? Is one line concatenated, or two? You have 
to carefully read the spec to determine which, and it matters because if two are 
concatenated then the declaration of x vanishes. And BrandX did it wrong, the 
customer wrote all their code this way, and it all broke with my compiler, and 
of course it was all my fault.

I thought "who in their right mind would write code that way?" At least I could 
justify myself with BrandX is a buggy compiler, but when the behavior is in the 
spec, I have no leg to stand on.

If we want to support interfacing with C++, we have to support badly written 
C++, because that is the NORMAL case. Telling them their code is **** and that 
they should rewrite it in order to work with D is never, ever going to work.

Another anecdote - Microsoft MASM in the 80's was full of bugs. I mean full of 
bugs. When Borland came out with an assembler, it wouldn't work with most of the 
ASM files out there. They finally had to engineer in what they called "quirks 
mode" to emulate MASM's bugs. Telling customers to rework their ASM files didn't 
work for a large company, either.


> are there any other additional benefits to the current design which I'm 
> overlooking?
> 
> With a non-scoped extern(c++) we could simply use two files.

Yes. But then you'll have the people who want a 1:1 correspondence with their 
C++ files and the corresponding D files. I happen to be one of those people, for 
the ease of maintaining a translation (and for comparing it with the original 
C++ source code if it is not behaving correctly).

Besides, I provided solutions for both Manu's case and Atila's (they are 
different), which are easier than "simply" breaking things up into multiple files.


> My conclusion is that _if_ I understood you correctly, it must mean that in the 
> examples which you have in mind, it is common to *bind* to two namespaces in the 
> same file? Could you give a real-world examples of two namespaces which you 
> would like to mix like that in the same *bindings* file? Is it for instance 
> 'std' and 'std::experimental'?

In D it is not allowed to have multiple modules in the same file. This can 
become deeply entrenched in the way one thinks about programming, to the point 
where one cannot conceive of doing it other ways, i.e. ways that C++ allows, and 
that I believe are poor practice, but people do anyway.

You can see this in the C++ backend. It is certainly not organized in a 
module-like manner. (It predates C++ namespaces, so doesn't use them.)