I would contend that single letter names for generics are the ideal state. They're intentionally not given a meaningful name, because if you can give them a meaningful name, you've modelled the data wrong. IMO, if you're giving a generic a name beyond T, Z, etc. the logic probably isn't really generic, and should be a concrete implementation instead.
For single param generic types I'd agree - i.e. with List<T> it's perfectly obvious what T is. But any generic with more than one type is obviously doing different things with each one and that needs to be explained. The obvious example would be a Map<Key, Value>.
Now that I've typed that out though it kinda seems that List<Value> would be clearer, if not for the years of getting used to List<T> being the standard.
You shouldn't be talking about the meaning of T from the consumers perspective, but you should be describing it at the level of abstraction that your generic code is operating at.
To touch on the Map example, I do think Map<K,V> is just as clear and saves keystrokes, so that's how I'd write it. The "meaning" of K,V doesn't come from their names, it comes from Map.
I suppose clearer is a question of semantics, but to me there's not any more information conveyed by writing List<Value> vs List<T> - we already know T is a "Value" (because it has to be, due to List).
The data structure itself should provide the needed context - if the base data structure is so complex that the meaning of its generic parameters isn't obvious, that may be a case where naming them makes sense... but to me it's also a code smell of square-peg-in-round-hole.
I think it mainly depends on your target audience. The reality is that, the first time they saw Map<K,V>, everyone had to stop and think about what it was. Then after the first time or two it's immediately clear. Same with i for looping.
So if your code targets beginners, especially ESL people, then the verbosity has value to make that first time as easy as possible. Then it becomes noisy and weights you down.
That's an "easy" case, but in my experience, it happens all the time (though it might be especially true in C++). Should I use that "advanced"/uncommon language feature? Do I use it, but document what it does because I expect most people that will read the code not to know about it? If I'm in a part of the code base where the C embedded engineers contribute frequently, I'm going to err on the side of verbosity/clarity. On a code base with experienced C++ Dev, less so.
Why would Map<K, V> save any keystrokes? You should not be implementing it yourself anyway, and when using it, you replace K and V with concrete types anyway.
> I suppose clearer is a question of semantics, but to me there's not any more information conveyed by writing List<Value> vs List<T> - we already know T is a "Value" (because it has to be, due to List).
Yes, I agree. However, think about functions taking 3 or more generic parameters. There's a much larger need for better information in that context
I'm usually in favor of conciseness for one or two type parameters (much less so for any more than that), but if you do go full-words, “Value” is not much more descriptive than “T”, like writing “argument” instead of “x” for not much benefit. “Element” would be more descriptive of the role of the type parameter relative to the List type.
