I think we may be able to support importing associated items using type-based resolution (like
Thing::FOO from the example) with some limitations.
Consider this import:
Prefix is a type and
AssocItem is something that potentially may be an associated item, but we can’t know that for sure without doing type checking, trait resolution, etc, because
Prefix may be a type alias that can include everything inside it including associated types.
On another hand, we cannot delay import resolution until type checking, it will raise compiler complexity enormously.
What we can do is to reserve slots named
AssocItem in all namespaces of the current module, (or at least type and value namespaces because associated items can only live there, but maybe the macro namespace as well, just in case) and create some kind of virtual items.
After that import resolution and other name resolution can work as usual possibly resolving paths to definitions of those virtual items.
Note that these greedily reserved imports may create more conflicts with other items than normal imports and will shadow glob imports (these are “some limitations” mentioned above).
When type checking is done we have all the necessary information and can figure out true definitions of these virtual items (possibly reporting errors if no such definition exists or it’s ambiguous).
Regarding generic arguments, I think we can consider them “not provided”.
So use of
AssocItem may be a “can’t infer type parameters” error, or it may be not if the parameters can be inferred or defaulted.
The alternative is the “generic argument transfer” hack employed for enum variants (
Enum::Variant<T> actually means
Enum<T>::Variant), but that would be bad because associated functions and soon types/constants may have their own type parameters unlike variants.