On Sun, 27 Apr 2014 15:54:51 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
http://wiki.dlang.org/DIP61
I think there is a big problem with name lookup here.
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ok
bar.func(); // ok, uses C binding (no name mangling)
}
In this case, even though the C function is not mangled or in any other
namespace, the module can be used for unambiguous calling.
But in your proposal, the name qualifiers could be either C++ namespaces
or D modules. This presents an unnecessary ambiguity.
e.g.
module foo;
void func() {}
module bar;
extern(C++, foo) void func(); // foo::func in C++ land
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ALSO error
bar.func(); // Not error, BUT it's actually calling foo::func from C++
land!
}
I think we cannot change name lookup rules for C++ symbols, because the D
module system already owns those.
An alternative is that you could create an alternate way to disambiguate.
Let's pick a strawman called _cpp, just to illustrate:
void main()
{
func(); // error still
foo.func(); // calls D's foo module's func
bar.func(); // calls D's bar module's func (defined as foo::func)
_cpp.func(); // error, _cpp denotes we are using namespace qualifiers,
and there is no global C++ func
_cpp.foo.func(); // calls D's bar module's func.
bar._cpp.foo.func(); // ditto
}
Really, _cpp could be anything. But I think hijacking D's module
qualifiers does not help. To make things seamless, you could make it ::,
but I know many people have objections to that.
-Steve
