extern(C++, ns)

[Marc Schütz via Digitalmars-d]

On Sunday, 3 January 2016 at 17:53:38 UTC, Walter Bright wrote:
> On 1/3/2016 9:14 AM, Marc Schütz wrote:
>> On Sunday, 3 January 2016 at 16:18:13 UTC, Walter Bright wrote:
>>> No. If D is to support C++ namespaces, it has to support 
>>> declaring the same
>>> identifier for different purposes in different namespaces. 
>>> C++ namespaces have
>>> different scopes in C++. Doing anything else would make it 
>>> impossible to
>>> connect to perfectly legitimate C++ programs. The WHOLE POINT 
>>> of C++
>>> namespaces is to support declaring the same identifier in 
>>> different namespaces.
>>
>> Yes, but the point of `extern(C++, ns)` is NOT to achieve the 
>> same in D! D has
>> its own mechanisms for that, primarily the module system, as 
>> well as hacks like
>> static structs. And I don't see how Manu's suggestion would 
>> make it impossible
>> to link to some C++ programs. Can you give an example?
>
> I did. You quoted it below :-)
>

But this is evidently not an example where it's "impossible to 
connect to perfectly legitimate C++ programs", because there are 
at least two practical ways to do so: 1) using the static struct 
hack, and 2) placing the symbols into separate modules.

>>>   namespace ns1 { int identifier; }
>>>   namespace ns2 { int identifier; }
>>>
>>> And why shouldn't they? It's correct and legitimate C++ code.
>>
>> I guess in reality this would not be a frequent thing. Most 
>> real C++ code will
>> have both instances of `identifier` declared in different 
>> header files, and D's
>> modules will usually closely mirror those, so they will end up 
>> in different
>> modules on the D side.
>
> My experience with "who would ever write such code" is they 
> exist and you cannot wish them away. In a more general case, we 
> should allow as much C++ compatibility as we can, because every 
> shortcoming will be complained about at length. And, as Manu 
> pointed out, one is often not able to adjust the C++ side of 
> the bridge.
>
> Besides, this isn't even an edge case. It's what C++ namespaces 
> are for.

I don't agree with this. Their primary purpose is to avoid name 
collisions between symbols from different projects (or parts of a 
project), or to establish a symbol hierarchy independent from the 
source tree layout, but not to allow the same symbol several 
times in the same header file. That may happen in a few cases as 
a side effect, but I wouldn't say that's what they are made for.

>
>
>> In the rare case
>
> That's a vast assumption. Manu is one programmer out of a 
> million.
>

Indeed I don't have statistics, but I think it's a reasonable 
assumption. We're talking about a very specific case here: that 
one C++ header declares symbols in several parallel (non-nested) 
namespaces. This is the only way the kinds of collision described 
by you can appear, if we stick to a 1:1 mapping between C++ 
headers and D modules. Do you have any real-world examples of 
that? I looked at several large C++ projects on Github, but 
couldn't find a single instance.

> Offhand, I can't think at the moment why that wouldn't work, 
> but using structs as C++ namespaces did have problems I don't 
> recall at the moment, and:
>
> 1. It's ugly.
> 2. You're an expert, and it's wrong - the fields need to be 
> 'static'. How will others fare?

Yeah, my bad. But note that it's easy to recognize that mistake: 
it will fail to compile the first time you try to access one of 
the members.

> 3. I suspect that this ugly thing will become "best practice", 
> and we won't be able to fix it in a backwards compatible way.

I merely wanted to show that there is a workaround if you 
absolutely need them to be declared in the same module. As Manu 
suggested, the usual and recommended way to handle this situation 
would be to put them in separate modules, along with other 
symbols in that namespace, no matter in which header file they 
are declared.

> 4. Structs carry other baggage with them, such as 'init' 
> fields, TypeInfo's, default member functions, etc.
> 5. I don't share the opinion that a C++ namespace introducing a 
> scope, just as it does in C++, is something weird and 
> unexpected.

It is an unexpected behaviour for `extern`: neither `extern(C)`, 
`extern(D)`, `extern(C++)`, `extern(Objective-C)`, nor any other 
affect scoping or symbol lookup, only mangling and calling 
convention.