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

[d-bugmail at puremagic.com]

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

--- Comment #5 from Max Samukha <maxsamukha at gmail.com> ---
(In reply to RazvanN from comment #4)
> (In reply to Max Samukha from comment #3)
> > How are imported symbols different than other symbols introduced by a mixin?
> 
> In the case of imported symbols, you are right, there isn't any difference,
> however, the problematic case is when you have module imports (`import
> std.stdio`) inside a mixin. In that case, you end up importing a lot of
> symbols that you have no idea about. The user can look through the code (or
> the documentation) of a mixin template and at least have a general
> understanding of the symbols that he is mixing in, whereas, in the case of
> imports there is no way you can know what symbols end up hijacking your
> other symbols (except if you audit all the imported modules).

Sorry for the slow reply.

Yes, my question was not so much about this particular case as about why
directly imported symbols are considered eligible for anti-hijacking measures,
while symbols introduced indirectly (via an imported base class/interface,
mixin, or "alias this") are not.

--