[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 #6 from RazvanN <razvan.nitu1305 at gmail.com> ---
(In reply to Max Samukha from comment #5)
> (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.

No worries.

> 
> 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.

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.

--