[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

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

--- Comment #20 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Mathias Lang from comment #18)
> Feel free to reach out to me by email if not.

In the interest of keeping the discussion public, I'll just reply here.

> Now there is something special about 'mixin template' and 'class' /
> 'interface' declaration: they are the only remote (as in, outside of the
> module) symbol one can inherit it's scope from. 
> 
> But inheriting the imports leads to the same issues 10378 describe: you can
> end up in a situation where adding a symbol to module 'foo' which is
> 'protected import' of class 'A' will suddenly change which symbol is
> selected in subclass 'B : A'. However, if you have both imports at the same
> level, you'll get a conflict.

I think what you are saying is that a mixed in template could affect existing
*imports*, right? But an import can already do that! Ignoring imports with
mixins doesn't fix this problem.

The mixin could not hijack local symbols, right? I thought that was the larger
point -- you are referring to class/local symbols, or even module functions,
and suddenly that changes through a hijacked import.

I get that it's good to prevent hijacking as much as possible. But this doesn't
disallow hijacking to any further degree than is already disallowed. In other
words, preventing mixins from hijacking imported symbols doesn't remove the
problem, and just makes the language inconsistent.

> The only kind of hijacking I can think of ATM is when an import which is
> more nested than another one introduce an already-used symbol.
> 
> E.g. if this class used 'b.myFunc' before and a new library introduce
> 'd.myFunc':

Right, but this still exists. Why prevent it in the case of a mixin?

For example, d could public import x. x could define myFunc. This is pretty
much equivalent to the mixin case.

--