Splatting creates spurious warning about extending function without using module defined typed arguments

[CameronBieganek]

[pfitzseb]

At least the first case is valid, no? You define Base.cat(us::Union{}; dims::Integer) there, which looks like piracy to me.
Dunno where the types come from in the second case, so maybe that actually is a bug.

[CameronBieganek]

You define Base.cat(us::Union{}; dims::Integer) there

Hmm, I'm not following you. The signature in that function definition is

Base.cat(us::UnivariateFiniteArray{S,V,R,P,N}...; dims::Integer) where {S,V,R,P,N}

Notice that in the second screen capture, the warning goes away after removing the splatting.

That code is from MLJBase.jl. Here's a link.

Here's a reproducible example:

struct A
    x::Int
end

Base.cat(a::A...; dims::Integer) = a.x + 1

(I deleted the second example since I can't reproduce it.)

EDIT: Sorry I was too lazy last night to add explanatory notes to the screenshots and come up with a reprex. 😂

[pfitzseb]

You're defining Base.cat for zero arguments as well with that definition:

julia> f(xs::Int...) = xs
f (generic function with 1 method)

julia> f()
()

julia> f(1)
(1,)

julia> f(1,2)
(1, 2)

julia> f(xs::Float64...) = "float"
f (generic function with 2 methods)

julia> f()
ERROR: MethodError: f() is ambiguous. Candidates:
  f(xs::Int64...) in Main at REPL[1]:1
  f(xs::Float64...) in Main at REPL[9]:1
Possible fix, define
  f()

[pfitzseb]

Oh, and the usual fix for this is to define f(x::Int, xs::Int...) instead (although you might be able to do something smarter).

[CameronBieganek]

Oh, ok, makes sense. I didn't write that code, but I'll make a PR to MLJBase.

Although it does seem a little odd to me that foo(args...) also defines the foo() case. It seems to me that the costs of including the zero argument case in a vararg definition are greater than the benefits.