On Mon, 28 Apr 2014 10:54:17 -0400, Steven Schveighoffer wrote: >>> >>> That doesn't help. foo.func() is still ambiguous. With this proposal, >>> you have hijacked the meaning of namespace lookup. When I say x.y.z, >>> it doesn't just mean look for symbol z in module x/y.d, it can also >>> mean to look for symbol z in C++ namespace x::y. This was not the case >>> with C binding, which continued to use D modules for symbol lookup. >>> >>> Consider that a boatload of C++ code is named std::something. Now, >>> std.string has an ambiguous meaning wherever it is used! >>> >>> -Steve >> >> bar is renamed, thus you have to access via _cpp.[namespace] renames >> were added to prevent hijacking. > > That renames the bar module, but not the foo C++ namespace, which can be > assumed when calling foo.func. > > In reality, you could "fix" the situation by renaming the foo D module, > and then foo.func would unambiguously refer to bar's func :) > > Another alternative fix would be to allow renaming C++ namespaces. I > strongly recommend against that. The better alternative is to reserve > qualified name lookup to D modules alone. Adding a mechanism that is > possibly ugly, but that does NOT conflict with module lookup, in order > to disambiguate C++ symbols is fine. > > -Steve
I am confused now, cross module renaming?? I was thinking this: a.d extern(C++, std) { ... class string ... } b.d import std.string; import cpp = a; // a must be accessed via cpp std.string.... /// okay D version cpp.std.string ... /// okay c++ version string ... /// Okay D version cpp.string /// Okay C++ version