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

[Mathias Lang]

On Tuesday, 31 July 2018 at 08:33:52 UTC, Daniel N wrote:
> On Monday, 30 July 2018 at 13:48:46 UTC, Atila Neves wrote:
>> On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
>>> On 7/28/2018 11:18 AM, Manu wrote:
>>>> Make a PR that implements namespace as a string... I will 
>>>> use that fork of D forever.
>>>
>>> 1. Look how it is mangled on the C++ side. (Use "grep" on the 
>>> object file.)
>>>
>>> 2. Use:
>>>
>>>    pragma(mangle, "the mangled name")
>>
>> This doesn't work for templates. If it did I wouldn't have an 
>> issue since libclang tells me what the mangling is.
>
> What is the deal-breaker with templates? For simple functions 
> libclang + pragma seems the best option right now.
>
> template fun()
> {
>     pragma(mangle, "_ZN2ns3funEv")
>     extern(C++)
>     void fun() {}
> }
>
> mixin fun;

Your template doesn't have any template parameter. Bear in mind 
mangling is dependent on the instance, not the declaration.

Once you add some template parameter, you need to mangle your 
template parameter list, which you could *almost* reasonably do 
with CTFE, but since you are on POSIX, you also got fun things 
like components and template parameter substitution.

Example:
```
     struct Array16479 (Arg) { Arg* data; }
     Array16479!(FuncT2) func16479_4 (FuncT1, FuncT2) (FuncT1);
     static assert(func16479_4!(int, float).mangleof
                   == `_Z11func16479_4IifE10Array16479IT0_ET_`);
```
As you see the return value (`Array16479IT0_E`) encode a 
backreference to the symbol's template parameter: T0_ reference 
the second template argument.
If you throw some more language features (e.g. aliases) you 
quickly realize you need a full semantic analysis to get the 
mangling right on templates.

More test cases/examples (and shameless self plug): 
https://github.com/dlang/dmd/pull/8455/files