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

[Walter Bright via Digitalmars-d]

On 4/28/2014 4:30 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Monday, 28 April 2014 at 19:32:10 UTC, Walter Bright wrote:
>> On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad"
>> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>> No. Even though they are the same function as far as the signatures are
>> concerned, they are different functions as far as the D type system is
>> concerned, and hence the call is ambiguous. You'll have to qualify by
>> framework1.std.something() or framework2.std.something().
>
> So you have to choose between framework1 and 2's version if std::string when
> building your own class, an then cast back and forth between the different
> framework bindings even though the actual type is the same? Isn't that tedious?

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.

The SAME issue exists with D imports. DIP61 does not change this.


> But I think that it is a problem that std.something is silently rebound to a
> different function.

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.


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


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