Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

which() reports "no method found" when there is an ambiguity #22988

Closed
zsunberg opened this issue Jul 27, 2017 · 4 comments · Fixed by #23603
Closed

which() reports "no method found" when there is an ambiguity #22988

zsunberg opened this issue Jul 27, 2017 · 4 comments · Fixed by #23603

Comments

@zsunberg
Copy link
Contributor

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

error("method match is ambiguous for the specified argument types")
, 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
Copy link
Member

StefanKarpinski commented Jul 28, 2017

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

@martinholters
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants