Be less aware of when Julia avoids specializing?

[MilesCranmer]

+1

Or at least having much more sensible defaults given the current state of Julia precompilation and package extensions. I could see having a larger upper bound for Vararg non-specialization be an easy improvement. Right now it seems too extreme imo:

julia> f(x...) = x

julia> Base.specializations(@which f(1, 2))
Base.MethodSpecializations(MethodInstance for f(::Int64, ::Vararg{Int64}))

which is not great when, as you mention, it’s often encouraged to write generic code without worrying about lost performance.

Also worth noting that the Vararg specialization rules are currently so complicated they seem to result in unexpected behavior when you combine them with other non-specializing types:

Specialization on vararg of types

I don’t know if it was left out for some good reason, but the Vararg section is actually pretty vague about what is being specialized. Unlike lone functions and types, Vararg specifies multiple types with a possibly fixed arity. From what I could tell (though you should probably verify yourself), the “nonspecializing” __(x::Int...) specializes on Int just fine, it’s the arity it gives up on. Even __(x...) specializes on the first argument’s type in 2 specializations, one where the rest of the t…

I think simpler rules would generally be better if the specialization behavior is changed.