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

[Steven Schveighoffer via Digitalmars-d]

On Mon, 28 Apr 2014 11:29:53 -0400, Byron <byron.heads at gmail.com> wrote:

> On Mon, 28 Apr 2014 11:21:52 -0400, Steven Schveighoffer wrote:
>
>> On Mon, 28 Apr 2014 11:09:38 -0400, Byron <byron.heads at gmail.com> 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