Sure, but Julia doesnâ€™t know that by the method signatures alone. Simple example:

julia> f(::Array{T,N}, ::Vararg{Int64, N}) where {T,N} = "ints!"
f (generic function with 1 method)
julia> f(::Array{T,N}, ::Vararg{Symbol, N}) where {T,N} = "symbols!"
f (generic function with 2 methods)
julia> f(zeros((3, 5)), 1, 2)
"ints!"
julia> f(zeros((3,)), :one)
"symbols!"
julia> f(zeros(()))
ERROR: MethodError: f(::Array{Float64, 0}) is ambiguous. Candidates:
f(::Array{T, N}, ::Vararg{Int64, N}) where {T, N} in Main at REPL[19]:1
f(::Array{T, N}, ::Vararg{Symbol, N}) where {T, N} in Main at REPL[20]:1
Possible fix, define
f(::Array{T, 0}) where T

Thatâ€™s a 2-dimensional dataset with zero elements. A theoretical 0-dimensional dataset would be a GMTdataset{Float64, 0} and have exactly one element.

I think itâ€™s worth adding that ambiguities arenâ€™t necessarily a problem. Yes, theyâ€™re sometimes code smells of a bad design and they sometimes describe a case that you forgot about, but they can also describe an operation thatâ€™s otherwise nonsensical.

It can be useful to keep Test.detect_ambiguities empty just to help you find those problem cases, but thereâ€™s otherwise nothing wrong with leaving some ambiguities laying around.