On 4/28/2014 4:30 PM, "Ola Fosheim Grøstad"
<[email protected]>" 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"
<[email protected]>" 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.
