Missing ambiguity error for diagonal dispatch

[yuyichao]

I mentioned this in #20056 (comment) but looking at it again, I think it's probably unrelated/significantly different.

A simpler example for it is

julia> f(::Real, ::Real) = 1
f (generic function with 1 method)

julia> f{T}(::T, ::T) = 2
f (generic function with 2 methods)

julia> f(1, 1)
1

Since the two methods matches two intersecting sets, the intersection should be ambiguous.

A similar case was brought up in #20078 (comment) where Jeff proposed treating explicitly specified leaftype specially though it doesn't really apply to the case here.

[vtjnash]

Looks correct to me: Real <: Any

[andyferris]

What? No, in the former they can be different leaf types, but not the latter (unless that changed?). Neither signature is a subset of (ie more specific than) the other, but both match f(1,1).

[vtjnash]

A ∩ B ≠ ø ↛ ambiguity. All that's required is that A > B && B > C && A ∩ C ≠ ø → A > C (aka transitivity)

[yuyichao]

What's C?

[StefanKarpinski]

This is a little cryptic. Does the first statement mean that A ∩ B ≠ ø implies no ambiguity or that it does not imply ambiguity? Regarding the second statement, as @yuyichao said, what's C?

[JeffBezanson]

This is very similar to #3025. If specificity is limited to strict subtypes, then yes these are technically ambiguous. However I'm inclined to allow (Real,Real) to be more specific than (T,T), since the former definition presumably knows something about real numbers, while the latter definition is for any type at all (as long as you pass two things of the same type). Generally, declared sub-classes take priority over other aspects of types; for example Array is more specific than AbstractArray{Int}.

[vtjnash]

yes, this example was a bit simpler, but it's the same result & not a bug