On Mon, 28 Apr 2014 10:27:19 -0400, Steven Schveighoffer wrote: > 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
why not import _cpp = bar; ?