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

[via Digitalmars-d]

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.

> 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. You should be able to have A.foo and A::foo. It makes 
no sense to conflate the paths if they mangle differently.

>> 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?

>>> Remember, a C++ signature is the same as its type in C++, but 
>>> that is not true
>>> of D.
>>
>> And that makes it tedious to interact with C++?
>
> I don't see how it makes it any more tedious than dealing with 
> the ODR rule in C++ anyway.

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