Looking at it again, does look like something is odd. My original solution of putting val something1: bar.Something = Something("...")
does produce a compiler error–but I missed the importance of specific import overriding star imports.
The reason an error is expected is that import bar.Something
, which does not allow calling Something("String")
, could be expected block the import foo.*
star import’s Something
and continue to show an error.
So the final resolution is chosen in order of:
- single valid function/constructor ← this is the cause of the behavior. It’s done regardless of imports.
- specifically imported function/constructor
- star-imports function/constructor
- function with the more specific type (but ERROR on multiple classes)
If this behavior is bug, the bug would hold true for both functions and constructors. I can see why this feels risky. You might be using a getProperty()
function throughout a file. You hope all incorrect usages would be caught since you specifically imported the housing.getProperty
function but one wrong star import and you’d accidentally call the os.env.getProperty
function instead, potentially without knowing.
Any thoughts on reasonable ways to solve this? There’s always some risk you call the wrong function. Star imports have always carried the risk of them adding something that breaks your code–even specified imports blocked usages of potential mistakes based on similar names that risk will always exist.
Any solution that throws the expected error would be a breaking change. I wonder if warning and suggested action to add import aliases would be sufficient.