The type variable in any generic declaration is inherently unreadable. What's <T>? Every language with generics has tried to come up with ways of making this less opaque. Typeclasses, concepts, traits, interfaces, bounded type parameters. If you implement one of those then you'll have another unforeseen problem on your hands, playing wack-a-mole until you have C++.
How about just code gen your generic implementations then check them in. That way I can see what's going on without having to guess. The whole thing is about saving time typing and DRY right?
The type variable in any generic declaration is inherently unreadable.
The concrete type variable of a generic parameter does not matter at all, you need not to clutter your brain thinking over it.
With a simple T you do not know anything about the type and you cannot do anything else with it directly except using the root type methods of your type system (e.g get hashcode, toString, etc)
Most generics to be useful needs either:
1) To be type tested (e.g through reflection).
This allow you to manipulate it in a fine grained manner and you can know exactly what it's type is.
But generally we want
2) to abstract over many types in the same way because those type would have a same invariant, a same behavior.
Some language allows you to represent this through union types instead but there's nothing wrong to say that T extend an interface/concrete class that specify what will be accessed from T inside the function. There is no cognitive overhead, no ambiguity. What would have been many types become simpler, factorised under the same contract, the same interface.
If you implement one of those then you'll have another unforeseen problem on your hands, playing wack-a-mole until you have C++.
This is a claim, could you explain it?
I see no reason to think that way.
C++ "generics" are cancer, we can agree on that.
How about just code gen your generic implementations then check them in.
I'm not sure to understand.
Would that be like C++ template? What's the difference?
You would like the N redundant implementations of a generic function to be visible? Why desire this clutter?
And the alternative, manually maintaining redundant code is error prone and a maintenance burden. Also the fact that there is an invariant, a meaningful intersection of behavior between those types become hidden instead of being explicit through an interface/type test.
what's going on without having to guess. there is zero guess involved as explained above, it's all type safe and your IDE will autocomplete only the shared behavior.
How about just code gen your generic implementations then check them in. That way I can see what's going on without having to guess. The whole thing is about saving time typing and DRY right?