You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This adds a warning for the auto-import of types cases (#25744) that we
have long considered a bit of a bug, but didn't want to change because
it is too breaking.
The reason to do it now is that the binding rework has made this case
more problematic (see #57290). To summarize, the question is what
happens when the compiler sees `f(x) = ...` and `f` is currently and
implicitly imported binding. There are two options:
1. We add a method to the generic function referred to by `f`, or
2. We create a new generic function `f` in the current module.
Historically, case 1 has the additional complication that this error'd
unless `f` is a type. It is my impression that a lot of existing code
did not have a particularly good understanding of the resolved-ness
dependence of this behavior.
However, because case 1 errors for generic functions, it appears that
existing code generally expects case 2. On the other hand, for types,
there is existing code in both directions (#57290 is an example of case
2; see #57302 for examples of case 1). That said, case 1 is more common
(because types tend to be resolved because they're used in signatures at
toplevel).
Thus, to retain compatibility, the current behavior on master (where
resolvedness is no longer available) is that we always choose case 2 for
functions and case 1 for types. This inconsistency is unfortunate, but I
tried resolving this in either way (making all situations case 1 or all
case 2) and the result was too breaking.
Nevertheless, it is problematic that there is existing code that expects
case 2 beavior for types and we should help users to know what the
correct way to fix it is. The proposed resolution is thus:
1. Retain case 1 behavior for types
2. Make it a warning to use, encouraging people to explicitly import,
since we generally consider the #25744 case a bug.
Example:
```
julia> module Foo
String(i::Int) = i
end
WARNING: Type Core.String was auto-`import`ed in `Foo`.
NOTE: This behavior is deprecated and may change in future Julia versions.
NOTE: This behavior may have differed in Julia versions prior to 1.12 depending on binding resolution.
Hint: To retain the current behavior, add an explicit `import Core: String` in Foo.
Hint: To create a new generic function of the same name use `function String end`.
Main.Foo
```
(cherry picked from commit 8c62f42)
0 commit comments