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

[Laeeth Isharc]

On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
>
> The difference is they would have to rework their existing 
> code. If you are writing D source code bindings for your code, 
> then you are essentially writing new code. You don't have to 
> worry about backwards compatibility.

Why would you write bindings if the computer can do it for you, 
better, faster and consistently?

That's the idea behind DPP.  You can just #include C headers and 
they will be translated before compile time.  This is very 
helpful with projects like HDF5 that consider it acceptable in a 
minor release to replace a function with a macro.

Wrappers are a bit different.

In time C++ will follow.

> Not only that, who do you think even writes bindings for 
> libraries? Most bindings are done by the community for 
> libraries to other languages. How many companies do you know 
> have bindings for their C/C++ libraries for D, that maintains 
> them?

We do for a few things - for other peoples' libraries not our 
own.  But it would be better not to have to write bindings at all.

> damn hell no. That's what modules are for. So why are you 
> trying to implement namespaces in D under the guise of C++ name 
> mangling.

I don't think either Manu or Atila want to be able to sneak in 
namespaces by the backdoor.  They just want to be able easily to 
control namespace mangling of C++ linkage symbols.

What extern(C++) should be used for is allowing you
> to call C++ code from D, not to be able to format C++ code into 
> D. The only problem you have with breaking code up into 
> multiple files is that it isn't 1:1. That's not a technical 
> problem, it's a problem of conflicting personal opinion. If 
> it's not 1:1, who cares? If some some odd reason you have two 
> namespaces in one file in C++, odds are they are probably 
> separated in that one file anyway. If not and for some reason 
> the the code has multiple namespace definitions smashed 
> together into one file, flip-floping between namespaces. That's 
> not D's problem to fix the project's poor organization method.

For automatically translated bindings I think that the request is 
not unreasonable because there's considerable value in being able 
to just #include C++ headers as you can already with C headers 
and just call the C++ code from D.  D doesn't have libraries?  
Well it's got 1500 on code.dlang.org plus C and C++ libraries.  
What is it you think is missing?  That's a good retort!

I understand from Atila present choice just makes it a lot more 
complicated, not impossible.