On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright
<newshou...@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.g...@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
