Automatically resolve most method ambiguities #47325
Labels
feature
Indicates new feature / enhancement requests
needs decision
A decision on this change is needed
types and dispatch
Types, subtyping and method dispatch
Motivation
ChainRulesCore.jl defines
MultivariatePolynomials.jl defines
How are we supposed to resolve
*(::AbstractThunk, ::RationalPoly)
?Neither ChainRulesCore.jl nor MultivariatePolynomials.jl have any relation to each other or reason to be direct dependencies.
One option is weak dependencies, but this requires the package authors to be aware of each other and one of them to take action (add glue code) to ensure interoperability.
Proposal
Another option is to establish method precedence that is more opinionated than
<:
.I porpose the folowing rule:
Look at components recursively and from left to right, resolving the ambiguity with the first unambiguous component.
This is not a breaking change, as it should not reverse the precedence of any currently unambiguous method pairs.
See also previous discussion on discourse
To clarify the interpretation, for parametric types, this means first compare the body and then the parameters
First{Second, Third}
. Subtypes are preferred over supertypes, values are preferred over types, and typevars are compared first based on their upper bound and only then based on the set of previous usages of that type var. Types are equvalent to typevars without any preivous usages.Tuple{Dict{T, U}, V} where T <: Integer
is preffered overTuple{Dict{T, T}, T} where T <: Integer
which is preffered overTuple{Dict{<:Integer, T}, T} where T <: Integer
andTuple{Dict{T, <:Integer}, T} where T <: Integer
, but the final two are ambiguous. For unions, only prefer one union over another if every member of the first has a member in the second that it is either preffered over or is equal to. Types with more specified parameters are preffered over types with fewer if all the common parameters have no precedence.To further clarify the intpretation, here is an implementation of the proposed semantics with a `prefer`:
Emperical analysis
I loaded many popular packages (all but one of the 499 packages with at least as many downloads as Articfacts.jl, including all the standard libraries) and ran `Test.detect_ambiguities(mods...; recursive=true)` This yielded 7652 ambiguities. Of these, 7586 (99.1%) would be reolved by the proposed precedence rules in the `prefer` function above. A sample of 20 randomly chosen resolutions to check if they are good or not (currently they are ambiguous method errors) reveals my ignorance of obscure methods in the julia ecosystem. I attempted to code them as good or bad, and here are my notes; the methods listed first are prefferred over the methods listed second:
The text was updated successfully, but these errors were encountered: