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

[Rubn]

On Thursday, 2 August 2018 at 04:59:52 UTC, Walter Bright wrote:
> On 8/1/2018 7:09 PM, Rubn wrote:
>> On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright 
>> wrote:
>>> An example of silent hijacking:
>>>
>>>    extern (C++, "ab") void foo(long); // original code
>>>    ... lots of code ...
>>>    extern (C++, "cd") void foo(int); // added later by 
>>> intern, should have been
>>>                                      // placed in another 
>>> module
>>>    ... a thousand lines later ...
>>>    foo(0); // OOPS! now calling cd.foo() rather than 
>>> ab.foo(), D sux
>>>
>>> You might say "nobody would ever write code like that." But 
>>> that's like the C folks saying real C programmers won't write:
>> 
>> You can do that today, just remove the "extern(C++, ...)" part 
>> and you have the same issue. Why should C++ with namespaces be 
>> safer than just regular D ? I don't understand, if it is such 
>> a huge gigantic problem why didn't you do anything to solve 
>> this problem in regards to D then ?
>
> The difference is those names are supposedly in different 
> namespaces, given that the code is converted from C++:
>
>     namespace ab { void foo(long); }
>     ... lots of code ...
>     namespace cd { void foo(int); }
>
> where the foo()'s do not conflict with each other, and a user 
> would reasonably expect that same behavior when translated to D.
>
>
> If you *want* them in the same scope in D, you can do that with 
> alias.

You can say the same thing in D. If you have "module ab" and 
"module cd", if you put the function in the wrong file, you will 
face this same bug. It's not a hypothetical, it's the current 
implementation in D, yet no one has complained or filed a bug 
report about it.

The bug is caused by the implicit conversion from int to long. 
That is not, nor should it be, the purpose of C++ namespaces in D 
to fix.