DIP61: redone to do extern(C++,N) syntax

[Walter Bright via Digitalmars-d]

On 4/28/2014 11:06 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote:
>> First off, I expect "std" to be put in core.stdcpp.std, and then imported. So
>> this issue would only happen if 3rd party A and 4th party B each imported 5th
>> party C. Yeah, it'll happen, and it'll still work, as the import system
>> regards the same file as being the same import regardless of the import path
>> used to get to it.
>
> No, it'll happen if they use the same vector library an #include the same
> "vector3D" and independently specify their own binding? But if they cooperate
> and use the same binding, then you are ok? That makes no sense.

I simply don't know what you're talking about when you use the word "binding".


>> It's no different than if you have:
>>
>>    A::foo()
>>
>> in one framework, and a different:
>>
>>    A::foo()
>>
>> in another framework. It won't work in C++, either.
>
> That is only true if you mangle D modules and C++ namespaces the same way.

C++ identifiers do not get the module name mangled in.


> You should be able to have A.foo and A::foo. It makes no sense to conflate the paths
> if they mangle differently.

There is no A::foo in D.


>>> The problem is that you are forced to qualify the D-binding rather than the path
>>> of the cpp function. This will only work out ok if different framework authors
>>> cooperate.
>>
>> Not correct. This is not a problem.
>
> I can mix two independent cpp bindings without casting?

Casting has nothing to do with symbol lookup.


> Why not? It only applies to the translation unit. I see no relationship.

I'm sorry, I do not understand what your mental model of how this works is. 
Perhaps if you wrote your questions in terms of D code examples, I can answer them.