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.