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

[tide]

On Saturday, 4 August 2018 at 01:45:44 UTC, Laeeth Isharc wrote:
> 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?

With the current tools the ones that generate D files to be used 
aren't very good. They evaluate Macros based on the current 
implementation, so if there's a define MACHINE_X86 or 
MACHINE_x64, those macro and #if's will be evaluated based on the 
current system running the tool instead of generating equivalent 
version() statements.

> 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.

I wouldn't call that the same thing as what generally defines a 
wrapper. It's a different concept that does the work at compiler 
time. If I remember correctly Clang has something similar, where 
two languages can call each other once they have been compiled to 
Clang's intermediate format. Or at least it was something that 
was being worked on a while ago, never used it though.

>> 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.

It would be, but I don't think it'll ever be 100% and will 
require manual intervention.

>> 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.

Never said they did, but that's what Walter and the current 
implementation seem to indicate. I'd rather just have extern(C++) 
be what extern(C++) and extern(D) do, just change the name 
mangling, not try to emulate some features of namespaces like it 
currently does.

> 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.

The only person I've seen that wants this is Walter. I haven't 
seen anyone else show interest in wanting a 1:1 correlation. It's 
unreasonable, D isn't C++ nor should it be trying to strive to be 
C++.

Where are const pointers? Where are default constructors for 
structs that make structs not POD anymore, that changes the 
calling convention used in C++ (on Windows at least).