Wrong number of methods after redefinition of function about julia HOT 6 OPEN

IIRC @vtjnash said this was intentional, but there was much complaining from pretty much anyone, so I think we need to think about this again, possibly by tweaking the display code to only display methods that are reachable in the current world.

from julia.

Bisected to #53415

from julia.

How about the following: We change the display code to only count methods which are reachable in the current world for some signature. Now, I don't believe we have that exact query in the type system, but I think something along the lines of typesubtract(m.sig, mapreduce(m2->m2.sig, Union, filter(!=(m), methods(m.sig)) !== Union{} would be pretty close. It's a little expensive to compute, but probably doesn't matter for interactive showing.

from julia.

I don't believe we have that exact query in the type system

It is exactly the query you get if specifying lim != -1, though it indeed is expensive. Of note though that this can be approximated quite well with a O(1) pair-wise check (and which is an exact if there is no ambiguities), as two type-egal methods must be adjacent in the output list, per the definition of morespecific, after filtering ambiguities.

from julia.

This also seems unexpected:

f() = 1
f() = 2

julia> methods(f, Tuple{})
# 1 method for generic function "f" from Main:
 [1] f()
     @ REPL[15]:1

julia> methods(f, Tuple{Vararg{Any}})
# 2 methods for generic function "f" from Main:
 [1] f()
     @ REPL[15]:1
 [2] f()
     @ REPL[14]:1

from julia.

The behavior of lim==-1 has always been that way for whether it chooses to filter out supertypes. I suppose because it happens to be O(n) whereas the filter for the general case is O(n^3), where n is the number of methods that matched

from julia.