DIP61: redone to do extern(C++,N) syntax

[Steven Schveighoffer via Digitalmars-d]

On Sun, 27 Apr 2014 15:54:51 -0400, Walter Bright  
<newshound2 at 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