https://issues.dlang.org/show_bug.cgi?id=15925
--- Comment #21 from Steven Schveighoffer <schvei...@yahoo.com> ---
To add to this, I think the use case being held as the example that shows why
this was done is:
a.d:
module a;
struct S {}
void foo() {}
void m(S s) {}
// uncomment to hijack!
// void bar() {}
b.d:
module b;
class Foo
{
import a;
S s;
}
c.d:
module c;
void bar() {}
d.d:
module d;
import b;
import c;
foo();
class Bar : Foo
{
void x() {
foo();
bar();
s.m();
}
}
So x calling foo calls local foo. That's fine, with new import rules, nothing
outside of d.d can change that. The fix is to avoid calling a.bar if it was
added at a later time.
But what about the prevention of Bar from seeing m? Surely, when we want to
include an S member, we want to include it's entire interface. Now if some
other module defines an m that accepts an S, then s.m means something different
in Bar than it does in Foo! This can't be the right solution, can it?
This seems like it was broken before, and is broken in a different way now.
It's impossible to tell what the original code "wanted" to do. But it seems
pretty clear to me that Foo has a certain view of what an S API looks like, and
it meant to forward that view to its subclasses.
I can at least document the change in my blog article, because even if this
decision is reversed, 2.071 is already out there.
--
