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

[Walter Bright]

On 7/30/2018 6:45 AM, Atila Neves wrote:
> On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
>> On 7/27/2018 10:28 AM, Atila Neves wrote:
>>> But all I'm trying to do here is tell the D compiler how to mangle symbols.
>>
>> Namespaces have semantic implications, too, such as overload resolutions. A 
>> namespace introduces a new scope, not just a mangling.
> 
> Should they, though?

They do in C++. That was the whole point of adding namespaces:

C:    void ns_foo();
C++:  namespace ns { void foo(); }


> Structs aren't namespaces, I wouldn't expect them to behave the same.

 From a language perspective, they are namespaces.


>> doesn't. Being able to crack open a scope and stuff more symbols into it at 
>> any point in a program is just madness :-)
> Perhaps, but that's how C++ works.

C++ has a lot of bizarre name lookup behavior.

> I didn't know about this and it makes things better, but it's not a real 
> solution to my problem.

See my other post doing this same thing with structs.


> I'm arguing that reopening should be allowed.

As detailed in another post, this opens a whole host of other problems. Even in 
C++, what names are visible in a namespace at any particular point in the 
compilation is a nebulous concept. (It is actually carefully specified, but you 
have to be a language lawyer / compiler implementer to know what they are - to 
the user it is erratic, random, and nebulous.)

C++ gets away with this **** because programmers assume the fault lies within 
themselves. That doesn't work for D - they assume I'm an idiot. I get the bill.

I posted a solution to Manu a couple times now, to you as a user it would look like:

    mixin(cppNamespace("ns", "void foo();"));

and can be done with D today.