ambiguity warning missing?

[vtjnash]

julia> function z(a::(Integer,Integer)...)
       println(4)
       end
# methods for generic function z
z(a::(Integer,Integer)...) at none:2

julia> function z{T}(a::(T,T)...)
       println(5)
       end
# methods for generic function z
z(a::(Integer,Integer)...) at none:2
z{T}(a::(T,T)...) at none:2

julia> z((1,2),(3,int32(3))) #good
4

julia> z((1,2),(3,3)) #oops, expecting 5
4

julia> function z{T<:Integer}(a::(T,T)...)
       println(6)
       end

julia> z((1,2),(3,4)) # ok, that's better but why?
6

[JeffBezanson]

Arguably, the 4 and 5 definitions are ambiguous.

[vtjnash]

If they are ambiguous, shouldn't there be a warning that 6 is needed?

Simpler demonstration of above:

julia> z{T}(x::T, y::T) = 1
# methods for generic function z
z{T}(x::T,y::T) at none:1

julia> z(x::Integer, y::Integer) = 2
# methods for generic function z
z(x::Integer,y::Integer) at none:1
z{T}(x::T,y::T) at none:1

julia> z(1,int32(2)) # good
2

julia> z(1,2) # maybe not?
2

[JeffBezanson]

Well, I do really think they are ambiguous. One is specialized for integers and the other accepts any type, but is more specific in that the arguments need to be the same type.

[vtjnash]

title updated to reflect possible issue

[StefanKarpinski]

From triage: this is now believed to actually be correct behavior; should be documented.

[JeffBezanson]

Example:

julia> zz{T<:Integer}(x::T, y::T) = 1

julia> zz(x::Integer, y::Integer) = 2

julia> zz{T}(x::T, y::T) = 3

julia> methods(zz)
# 3 methods for generic function "zz":
[1] zz(x::T, y::T) where T<:Integer in Main at REPL[8]:1
[2] zz(x::Integer, y::Integer) in Main at REPL[9]:1
[3] zz(x::T, y::T) where T in Main at REPL[11]:1

The current thinking is that this sorting is correct, since mentioning Integer should be more specific than T<:Any. In turn, both specifying Integer and a diagonal constraint is even more specific.

[StefanKarpinski]

In case it's unclear to anyone, methods prints methods in specificity order, so the above shows that the methods are defined in order of most to least specific.

[vtjnash]

doc issue is #23740. method sort ordering is consistent, so there's no bug