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.
