Feature request: Named type parameters

[MasonProtter]

As a 2.0 feature, I think we could add a lot of clarity (at the price of some verbosity) if one were allowed to name type parameters a la NamedTuples. For example AbstractArray{eltype=T, dim=N} would give a lot of clarity at a glance.

This gets even better when you consider subtypes. For example, if you show me aStaticArray{Tuple{3, 3}, Float64, 2, 9} I might not know what the heck I'm looking at, whereas StaticArray{size=Tuple{3, 3}, eltype=Float64, dim=2, length=9} is quite helpful at at glance.

[pablosanjose]

It's not completely clear to me whether your concern should be address in the show-implementation of a given type, or if there is something more to be gained by naming type parameters. If you are thinking about clarity when reading code, type parameters can be named however you like. Could you illustrate this further with a specific usecase that is inconvenient or not possible today?

[fatteneder]

Lately, I felt I need that functionality too and so I drafted a macro for this.
Funnily enough, I ended up not needing it after I got it to work. But after stumbling upon this issue, I now finished it up here: https://github.com/fatteneder/NamedTypeParameters.jl
The implementation relies on internals of UnionAll and TypeVar.
I have not yet tested it in a real application.

@MasonProtter Does this match your idea?

[elextr]

Would it be too radical to suggest people just use more expressive names for parameters, eltype not T and dim not N ?