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

[Steven Schveighoffer via Digitalmars-d]

On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 4/29/2014 9:13 AM, Steven Schveighoffer wrote:
>> But what happens when you add another import that conflicts?
>>
>> module foo;
>>
>> void func() {}
>>
>> module prog; // updated
>> import bar;
>> import foo;
>>
>> void main(){
>>     foo.func(); // now calls foo.func, and not bar.func as it  
>> originally did,
>> right?
>> }
>>
>> So by importing from another module, we have silently and drastically  
>> changed
>> the behavior. Have I missed something?
>>
>> Why is this not a problem?
>
> Because the compiler would now issue an error for that, it's its  
> anti-hijacking feature.
>
> Try it and see!

I agree! that was my central point, which Timon seemed to be arguing  
against :)

Quoting:

On Tue, 29 Apr 2014 11:43:45 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 04/29/2014 01:34 PM, Simen Kjærås via Digitalmars-d wrote:
>>
>> Building on this knowledge:
>>
>> module foo;
>>
>> void func();
>>
>>
>> module bar;
>>
>> extern(C++, foo) void func();
>>
>>
>> module prog;
>>
>> import foo;
>> import bar;
>>
>> void main()
>> {
>>      // Seems like it's ambiguous between foo.func and bar.foo.func.
>>      foo.func();
>> }
>
> It will call foo.func, because the module foo is in scope in module prog  
> and hence hides the namespace foo in module bar.
>
> You can already try this today, as the DIP _does not actually introduce  
> any new lookup rules_:
>
> module a;
> void func(){}
> //---
> module bar;
>
> mixin template X(){
>      void func();
> }
> mixin X foo;
> //---
> import foo,bar;
>
> void main(){
>      foo.func();
> }
>
> In particular, any problems you find with symbol lookup are actually  
> orthogonal to the DIP.


-Steve