That’s unfeasible because symbols can refer to different functions in different modules and a generic function can change its behavior and results dynamically, but a type and its instances’ structure cannot. As a consequence, those type parameters you’re trying to condense are necessary for adapting to method changes. That massive (and as far as I’m aware, internal) Extrapolation type is rooted in many method calls, and as far as the language is aware, any of them can change behavior and result in a different return type of cubic_spline_interpolation, even though nobody would do that in practice.
ComputedFieldTypes is no exception, it omits the full type parameters from the constructor methods, but they still must exist and are still printed that way. Here’s an earlier example. I’m not certain, but I think it is hypothetically possible for unchangeable and pure built-in functions like <: to allow very limited field type computation.
Let’s simplify your example. You effectively want to do something like:
julia> struct Foo{T}
vec::Vector{T} # longer to type than T
end
julia> Foo([1])
Foo{Int64}([1])
but with an instantiating method instead of explicitly typing the type out, like
struct Foo{T}
vec::typeof(ones(T, 1)) # not valid code
end
But this is impossible because Foo{MyType} becomes several concrete types with different vec field types depending on how I redefine Base.ones(::Type{MyType}, dims) (don’t do this in practice). The only way for Foo{MyType} to be a valid type is to have vec::Any to accommodate all possible results of the field type computation. Going back to your example, itp::Any is necessary to adapt to various cubic_spline_interpolate calls in practice because the concrete type of itp also depended on the 0:0.1:0.2 input; even if we pretended methods were set in stone so parameters could be condensed, T for the zeros input was not enough. You can make a Foo constructor that computes T from itp before calling Foo{T}(itp, args...).