disallowing `Tuple{Union{}}` makes `hasmethod` less powerful.

[oscardssmith]

In 1.9: it was possible to qurery the method table to see whether a given function has a 2 argument method: e.g.

julia> g(u::Float64,p) = u

julia> hasmethod(g, Tuple{Int, Int})
false

julia> hasmethod(g, Tuple{Any, Any})
false

julia> hasmethod(g, Tuple{Union{}, Union{}})
true

However on 1.10, we can't express Tuple{Union{}, Union{}} so we can't express it like this (instead you have to do something like searching through all methods which can't be done at compile-time.

This is closely related to https://github.com/JuliaLang/julia/issues/52385, but IMO is sufficiently different to be worth separating into a separate issue.

[vtjnash]

  julia> hasmethod(g, Tuple{Union{}, Union{}})
  true

This result seems like bug: it probably should have returned false, since Julia may assume that the method list queries obeys subtyping transitivity, while that method cannot be called / does not exist for all supertypes of the input query. That is a bug in v1.9 though, and gets fixed (not a regression) in v1.10.

[topolarity]

that method cannot be called / does not exist for all supertypes of the input query

What supertype can it not be called for?

[nsajko]

What supertype can it not be called for?

Tuple{Int, Int}:

• is a supertype of Tuple{Union{}, Union{}}
• isn't associated with a method of g

Not that I understand what's going on here, though.

[topolarity]

But that's also true for:

julia> g(::Union{Int,Float64}) = 13
julia> hasmethod(g, Tuple{Int})
true

Tuple{Int,Float32} is a supertype of Tuple{Int} and isn't associated with any method of g

I thought that hasmethod is supposed to return true iff the argtype provided is completely covered by any method definition. (IIUC, that's what @oscardssmith is expecting here too.)

[topolarity]

Is the disagreement about whether Tuple{Float64, Any} is a supertype of Tuple{Union{},Union{}}?