[Issue 21500] public import in mixin template in module a fails when module b imports a.
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Mon Feb 8 11:28:08 UTC 2021
https://issues.dlang.org/show_bug.cgi?id=21500
--- Comment #7 from Max Samukha <maxsamukha at gmail.com> ---
(In reply to RazvanN from comment #6)
>
> I think it would be much easier if you provided an example. Currently, I
> cannot find any scenarios regarding base classes, mixins or alias this that
> do not abide by the present rule.
To my understanding, D's concept of hijacking is about preventing silent
breakage of the client code after a change in the API of a third-party module
(according to https://dlang.org/articles/hijack.html). Consider these two
cases:
1)
module a; // third-party
// void foo() {} // uncommenting doesn't affect module b
module b;
import a;
void foo() {}
void main() { foo(); }
2)
module a; // third-party
class Base {
// void foo() {} // uncommenting silently breaks module b;
}
module b;
void foo() {}
class Subclass: Base {
void bar() { foo(); }
}
void main() {
(new Subclass).bar();
}
I wonder why case 1 is taken seriously, while case 2 is neglected. I suspect
there is some important subtlety here (such as Base's scope being subjectively
more "local" to Subclass than b's scope).
--
More information about the Digitalmars-d-bugs
mailing list