[Issue 21500] public import in mixin template in module a fails when module b imports a.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21500

--- Comment #7 from Max Samukha <maxsamu...@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).

--