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

[Timon Gehr]

On 29.07.2018 09:37, Walter Bright wrote:
> On 7/28/2018 11:06 PM, Nicholas Wilson wrote:
>> Then again I don't see any (non philosophical/compiler front end 
>> internal) issue why you can't reopen a namespace. D is supposed to be 
>> pragmatic, after all.
> 
> Consider if a template reopens a namespace and throws a few more 
> overloads in it. Then, what's in the namespace is dependent on which 
> expansions are done, in which order.

How would that work? I don't think this is possible.

> Throw in the inevitable circular 
> references. Do people write code like that? Sure as shootin', they do, 
> and they demand that it work, and file lots of bug reports about the 
> erratic behavior.
> ...

Well, they already can do this with the global scope.

> Next, consider a function body throwing a few more overloads in. Now, if 
> the function body is compiled or not (and the compiler tries to avoid 
> compiling bodies unless it has to) affects code that is outside of the 
> function.
> ...

Again, this does not seem possible.

> C++ is full of stuff like that. The difference is, when code fails in 
> some bizarre way, programmers blame themselves and throw money at Scott 
> Meyers to educate them on how to avoid writing such code. For D, they 
> blame me.
> 
> The last time we fixed scope lookup to make it more complicated was with 
> imports, and that took YEARS to sort out.
> 
> So I'm a little reluctant to add features that will result in a rat's 
> nest of problems I can neither explain nor fix, then someone will add 
> 4000 incomprehensible lines to fix 2 cases and add 5 or 6 bizarre 
> regressions in the process and people complain the compiler is unstable. 
> :-)

Well, for Atila, the only issue is that there cannot be two namespace 
declarations of the same name in the same source file. I don't think it 
is necessary to change scope lookup rules at all, just put declarations 
from namespaces with identical names into the same name space.

Note that we already need to define semantics for code like this:

struct ns{
static:
     int decl0;
     static if(is(typeof(reopenNS1))) mixin(reopenNS1);
}

int arbitrarily_many_intermediate_declarations0;

enum reopenNS1=q{
     int decl1;
     static if(is(typeof(reopenNS2))) mixin(reopenNS2);
};

int arbitrarily_many_intermediate_declarations1;

enum reopenNS2=q{
     int decl2;
     static if(is(typeof(reopenNS3))) mixin(reopenNS3);
};

static assert(is(typeof(ns.decl0+ns.decl1+ns.decl2)));

In terms of lookup, this is a similar problem to namespaces. I think 
Atila could probably even emit ugly code like this to solve his original 
problem, but it would slow down compilation unnecessarily. There are no 
new lookup issues here.