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

[Steven Schveighoffer via Digitalmars-d]

On Mon, 28 Apr 2014 10:50:09 -0400, Byron <byron.heads at gmail.com> wrote:

> On Mon, 28 Apr 2014 10:45:14 -0400, Steven Schveighoffer wrote:
>
>> On Mon, 28 Apr 2014 10:37:36 -0400, Byron <byron.heads at gmail.com> wrote:
>>
>>
>>> why not  import _cpp = bar;   ?
>>
>> That doesn't help. foo.func() is still ambiguous. With this proposal,
>> you have hijacked the meaning of namespace lookup. When I say x.y.z, it
>> doesn't just mean look for symbol z in module x/y.d, it can also mean to
>> look for symbol z in C++ namespace x::y. This was not the case with C
>> binding, which continued to use D modules for symbol lookup.
>>
>> Consider that a boatload of C++ code is named std::something. Now,
>> std.string has an ambiguous meaning wherever it is used!
>>
>> -Steve
>
> bar is renamed, thus you have to access via _cpp.[namespace]
> renames were added to prevent hijacking.

That renames the bar module, but not the foo C++ namespace, which can be  
assumed when calling foo.func.

In reality, you could "fix" the situation by renaming the foo D module,  
and then foo.func would unambiguously refer to bar's func :)

Another alternative fix would be to allow renaming C++ namespaces. I  
strongly recommend against that. The better alternative is to reserve  
qualified name lookup to D modules alone. Adding a mechanism that is  
possibly ugly, but that does NOT conflict with module lookup, in order to  
disambiguate C++ symbols is fine.

-Steve