Julia: which() reports "no method found" when there is an ambiguity

[zsunberg]

I believe the following behavior of which() is not intended:

julia> f(a::Int, b) = a+b
f (generic function with 1 method)

julia> f(a, b::Int) = a-b
f (generic function with 2 methods)

julia> f(2,2) # to highlight that there is an ambiguity
ERROR: MethodError: f(::Int64, ::Int64) is ambiguous. Candidates:
  f(a, b::Int64) in Main at REPL[2]:1
  f(a::Int64, b) in Main at REPL[1]:1
Possible fix, define
  f(::Int64, ::Int64)

julia> which(f, Tuple{Int,Int})
ERROR: no method found for the specified argument types
Stacktrace:
 [1] which(::Any, ::Any) at ./reflection.jl:823

Instead of saying that there is "no method found", which() should give an error indicating that there is an ambiguity. Looking at the source https://github.com/JuliaLang/julia/blob/2b983d41f064c39c0b73f6c7695cc13e0de45c03/base/reflection.jl#L878, it looks like an ambiguity error was intended. Blame shows that none of this code has changed for a while.

I think it's worth fixing or changing the error to say that it might be an ambiguity because it was quite confusing to me when debugging.

Sorry if this is a duplicate issue - it's not too easy to search for issues involving "which".

Also, my versioninfo():

Julia Version 0.6.0
Commit 9036443 (2017-06-19 13:05 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, sandybridge)

[StefanKarpinski]

Ambiguities are method errors: a method matches by definition only if it is the _unique_ most specific method matching the argument types.

[martinholters]

Yet there is the error("method match is ambiguous for the specified argument types") line in which which seems to be unreachable at the moment.

[zsunberg]

Yeah, I agree that an error should be thrown when there is an ambiguity, but it should say that there is (or may be) an ambiguity, not that there is no method. It is very confusing when there is a matching method right in front of you and it says no method found.

[zsunberg]

A quick and dirty fix would be to make the error say "no unique method match for the specified argument types" and to get rid of the unreachable "method match is ambiguous..." error. Then there would be no distinction between the two types of failures, but the error message would not be as misleading.