Stable API to strip type parameters from type

[cossio]

Is there a function to strip the type parameters from a type? For example:

strip_type_parameters(Array{Int,3}) # should return Array

There is one way to do this but it is not documented (pointed out by @jakobnissen):

strip_type_parameters(T) = Base.typename(T).wrapper

Therefore in principle it can change in future versions.

Why not have a stable API for this?

[vtjnash]

It would be the same function as supertype. It is not available as a means to force users to discover that the function they typically want is similar, as mentioned in the documentation at https://docs.julialang.org/en/v1/manual/methods/#Building-a-similar-type-with-a-different-type-parameter

[kimikage]

Probably this is a feature that end users rarely need. The end user usually knows what the base type is.
However, it is a useful feature for package developers. Even if it is not exported, it would be beneficial to have an official reference implementation.
That doesn't help to prevent the same questions over and over again, though.

[kimikage]

BTW, I think the idiom is often used with @pure. Is it generally safe?

Originally posted by @kimikage in #39952 (comment)

[cossio]

It would be the same function as supertype. It is not available as a means to force users to discover that the function they typically want is similar, as mentioned in the documentation at https://docs.julialang.org/en/v1/manual/methods/#Building-a-similar-type-with-a-different-type-parameter

supertype doesn't seem to do what I want.

julia> supertype(Array{Int,3}) # Here I want Array
DenseArray{Int64,3}

julia> supertype(Int) # Here I want Int
Signed

[StefanKarpinski]

The hardest part of this is coming up with a name. Given a good name, the implementation can just be in terms of the current internals with documentation and tests so that we don't break it in the future even if the internal change.

[kimikage]

With respect to terminology, we often use "abstract type"/"concrete type" in different ways depending on the context. However, that does not mean that the specifications for abstract type, isabstracttype() etc. are ambiguous.

IMO, a "good" name here should mean that users can reach the name. Requiring that the specification be strictly associable with the name would probably leave us with no choice but to introduce new terminology. 😅

[StefanKarpinski]

Maybe typename or basetype?

[jakobnissen]

+1 for basetype. typename is too confusing given Base.typename and the Core.TypeName type.