On Mon, 28 Apr 2014 11:29:53 -0400, Byron <[email protected]> wrote:
On Mon, 28 Apr 2014 11:21:52 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 11:09:38 -0400, Byron <[email protected]> wrote:
I am confused now, cross module renaming??
I was thinking this:
a.d extern(C++, std) { ... class string ... }
class string now has two fully-qualified names. a.string, and std.string
(assuming the current DIP is implemented).
b.d import std.string;
import cpp = a; // a must be accessed via cpp
This renames the a *module*, but not the C++ namespace. The C++
namespace is entirely separate from D's module imports.
So now, a's string has two names, cpp.string and std.string (still).
std.string.... /// okay D version
Error. Refers both to the std.string module, and the string class within
the std C++ namespace.
cpp.std.string ... /// okay c++ version
I don't think this would work either. This is a mix of D modules, and
C++
namespaces. The DIP does not mention this possibility.
string ... /// Okay D version
I think this may work.
cpp.string /// Okay C++ version
Yes.
-Steve
Awesome this help me understand your point. So why does the namespace
live outside of the module? They have to live in the imported scope?
Because C++ has no idea of D modules.
There are two things here, name mangling, and name lookup. The DIP rightly
allows proper name mangling, which is difficult to get right (I think even
on different platforms the mangling is different), but also overloads name
lookup. So you can access a C++ symbol via it's short name (string), it's
fully qualified D name (a.string) or it's fully qualified C++ namespace
name (std.string).
There is nothing that explains how you could use the module AND the C++
namespace to look up the unambiguous name. But even so, the C++ name
conflicts with a D module lookup. And you can only fix it by renaming the
D module. I'd rather the DIP not invalidate existing D name lookup, and
provide an alternate mechanism to use C++ namespaces for fully qualified
symbols.
-Steve
