Non-varargs methods take precedence over varargs methods in dispatch,
assuming both are applicable and there are no other ambiguities. For
example:
julia> f(x...) = 3
f (generic function with 1 method)
julia> f(x,y) = 4
f (generic function with 2 methods)
julia> f(3,4)
4
julia> f(7)
3
However, more specific types take precedence even if they are varargs:
julia> g(x::Int...) = 3
g (generic function with 1 method)
julia> g(x,y) = 4
g (generic function with 2 methods)
julia> g(3,4)
3
In your case, it is tricky, because your method is more specific in that it
is not varargs and is more specific in the type of the first argument
(ASCIIString <: String), but it is less specific in the type of the second
argument. Currently, this means:
julia> import Base.*; (*)(x::ASCIIString, y) = 42
* (generic function with 120 methods)
julia> "hello" * 3
42
julia> "hello" * "blah"
"helloblah"
However, I'm inclined to think that this is ambiguous, and hence there is a
bug here: when you define your method, it should issue a method ambiguity
just as it would in the non-varargs case:
julia> h(x::String, y::String) = x * y
h (generic function with 1 method)
julia> h(x::ASCIIString, y) = 17
Warning: New definition
h(ASCIIString,Any) at none:1
is ambiguous with:
h(AbstractString,AbstractString) at none:1.
To fix, define
h(ASCIIString,AbstractString)
before the new definition.
h (generic function with 2 methods)
This warning indicates that the method dispatch order is ambiguous and
hence Julia will dispatch h("a","b") to some arbitrarily chosen method.
