missing ambiguity warning for Integer vs. Union{Int,Float64}?

[jiahao]

In a meeting with @stevengj, @ivirshup, and @janvitek, we were surprised that the following code did not yield an ambiguity warning:

foo(x::Integer) = 7
foo(x::Union{Int,Float64}) = 8
foo(3) # returns 8

[jiahao]

More specifically, we'd like to think of Integer as an implicit union of all its subtypes, so it should behave similarly to

foo(x::Union{Int,ASCIIString}) = 7
foo(x::Union{Int,Float64}) = 8
foo(3) # ambiguous

[JeffBezanson]

Int is strictly more specific than Integer, and we allow adding Float64 without interfering with that. Giving priority to declared subtypes of abstract types, when possible, is an important priority for specificity rules.

[jiahao]

We couldn't find an update to the type ordering rules since the first Julia paper. If we followed the rules exactly as laid out there, the result is ambiguous because the intersection of Integer and Union{Int,Float64} is Int, which is strictly more specific than both.

In Section 2.10, p. 8, the only applicable rule for determining specificity is

Rule 3. The intersection of A and B is nonempty, more specific than B, and not equal to B, and B is not more specific than A.

The first three clauses are true when A = Integer and B = Union{Int,Float64} or vice versa. The last clause is undecidable because you have recursively go back to Rule 3. So strictly following this specification, we cannot conclude which is more specific.

So, is there an updated specification of the type ordering?

[jiahao]

In Jeff's PhD thesis there is also a description of specificity here, but here none of rules are applicable to this case.

[JeffBezanson]

Yes, there are extra rules regarding unions here:
https://github.com/JeffBezanson/phdthesis/blob/876be73a5aab9b034fac3eb9ea9d8f96713f786f/chap4.tex#L880
These rules are in fact applicable here.