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