[ENHANCEMENT] TypeParameters(Matrix{Float64})[eltype] === Float64

[mtfishman]

An idea for simplifying the implementation could be to have a wrapper type TypeParameters(T::Type) = TypeParameters{T}() that you can index into to get the type parameters, i.e.:

TypeParameters(Matrix{Float64})[:] === (Float64, 2)
TypeParameters(Matrix{Float64})[1] === Float64
TypeParameters(Matrix{Float64})[eltype] === Float64
TypeParameters(Matrix{Float64})[(ndims, eltype)] === (2, Float64)

It may not be all that helpful since it could just make it harder for type inference and I'm not sure how much it will help the implementation, but I think it is interesting as a thought experiment.

I think a lot of concepts can map to the TypeParameters wrapper, i.e. defaults can be based around get:

get(TypeParameters(Matrix{Float32}), eltype) === Float32
# Use default value
get(TypeParameters(Matrix), eltype) === Float64
get(TypeParameters(Matrix), eltype, Float32) === Float32
# Determine if a type is specified or not
get(TypeParameters(Matrix), eltype, nothing) === nothing

I'm not really sure setting/specifying parameters really fits this interface though, since setindex(TypeParameters(Matrix{Float32}), Float64, eltype) doesn't make much sense. Part of the motivation could be to try to decrease the number of functions in the interface of the package, which is a lot at this point.

[mtfishman]

In analogy to the set/@set interface of Accessors.jl, we can think of TypeParameters as defining a lens, i.e. it could maybe even be implemented as something like:

lens = @optic TypeParameters(_) # Obviously this is just a sketch to present the idea
lens(Matrix{Float32}) === (Float32, 2)
set(Matrix{Float32}, lens, (Float64, 3)) === Array{Float64,3}
set(Matrix{Float32}, lens[eltype], Float64) === Matrix{Float64}

Again, I'm not sure if it is worth it, but I think it is an interesting perspective and I like the idea of thinking through how the functionality of this package could be implemented through more general concepts and with fewer functions.