In the process of rewriting and documenting better ε-serde we have to discuss several times two subcategories of type parameters for a type `T`:
Type parameters that are the type of some field of T, as in field: A;
Type parameters that appear in the definition of some field of T, but they are not the type of the field, as, in field: Vec<A>.
The two categories may overlap, as a type parameter can appear in both ways.
Which names would you use? One idea is "field type parameter" and "auxiliary type parameter". But I would like to know how they resonate with other people, or if there's some established naming for this (I couldn't find anything).
Did you mean field: Vec<T>? Otherwise, where does A come from?
I think that the key difference is, that T is a type parameter when used in impl<T> or struct Foo<T> or the likes, while the field field: T is of the generic typeT or generic typeVec<T> respectively.
The type is parametrized by the type parameter T.
In the case of field: T the field is of the exact same type as specified by the type parameter T.
In the case of field: Vec<T> the field is of type Vec<T> which in turn is a generic type with type parameter T.
Hence, I suggest differentiating between the term type parameter and generic type respectively.
In both of your examples, you're looking at a field with a generic type with type parameterT.
NB: You can also have generic types with multiple type parameters: BTreeMap<K, V> is a generic type with two type parametersK and V.
In the context of the trait implementation coherence rules, this distinction is called “(un)covered”. However, the Reference is not very clear about introducing it, so if you use this term (which I think would be somewhat good) you should define it yourself too. But, it is definitely a term for the distinction you are asking for.
A type which does not appear as an argument to another type. For example, T is uncovered, but the T in Vec<T> is covered. This is only relevant for type arguments.