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

[tid3]

On Saturday, 4 August 2018 at 17:54:11 UTC, Jonathan M Davis 
wrote:
> On Saturday, August 04, 2018 12:18:21 tide via Digitalmars-d 
> wrote:
>> 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++.
>
> In general, it's easier for maintenance if there's a 1:1 
> correlation between C/C++ headers and D headers. It makes it 
> easier to update the D files, and it makes it easier to find 
> where something is in the D translation if you're already 
> familiar with the C/C++ version - or if you're reading 
> documentation for the C/C++ version and trying to translate 
> that into what you need to know to use the D version. For the 
> most part, the C bindings in druntime follow the layout of the 
> C headers that they correspond to precisely because doing so is 
> more maintainable and easier to navigate than if the D modules 
> were laid in a hierarchy that followed its own logic instead of 
> trying to emulate the layout of the C headers being translated. 
> In fact, some of the more annoying issues with the C header 
> translations in druntime come from places where the layout of 
> the C headers was not quite followed for one reason or another.
>
> So, I'd fully expect most C/C++ binding projects to have a 1:1 
> correlation between C/C++ headers and D headers, and I don't 
> think that Walter is at all misguided in that respect.
>
> That being said, in most cases, such a 1:1 translation would 
> work just fine
> if we had extern(C++, "NS"), and it just affected name 
> mangling. There would
> be corner cases where it did not, but they could be worked 
> around even if it
> meant that in that particular case, you lost the 1:1 
> translation - but as
> Steven pointed out, it actually would be pretty straightforward 
> to manually
> add the kind of namespace wrappers that the language currently 
> forces on you
> with extern(C++, NS) if we had extern(C++, "NS"). And of 
> course, if we
> actually ended up with both extern(C++, "NS"), and extern(C++, 
> NS), then you
> could just use the extern(C++, NS) construct in those corner 
> cases, though
> ultimately, I think that we'd be better off with just having
> extern(C++, "NS").
>
> So, I don't think that Walter is being misguided here in terms 
> of how he expects folks to be translating C++ headers. I just 
> think that his concern over some corner cases you get with bad 
> C++ code has caused him to make the current solution for 
> binding to C++ namespaces more complicated than it needs to be. 
> And I don't think that his concerns are misguided either. I 
> just think that he's just blowing them out of proportion given 
> how easy it would be to work around those issues with the 
> solution that Manu wants, whereas the common case suffers with 
> the current solution.
>
> - Jonathan M Davis

Alright that's fair but it still isn't ever going to be 1:1. I've 
done some stuff with C++ that used the fact that including 
headers is just a copy and paste. So I had header files that 
didn't have structures defined in them. You would define the 
structures before the including the header file so that it could 
be used with multiple different headers. There's no way you are 
ever going to get a 1:1 mapping of that into D. Let alone 
remotely similar, it would have to be completely different.

It's nice to have but you are never going to achieve a complete 
1:1 mapping unless you bring all of C++'s features. Even with the 
current implementation it doesn't allow multiple namespaces of 
the same name in the same D module. Yet Walter is hung up on that 
fact of that one edge case.