[TheLoneWolfling]

One common case that I've encountered:

There's no (good) way of going "this is a Comparable<Foo> and a Comparable<Bar>, but not a Comparable<Baz>" that's detectable at runtime. (Also true with other interfaces.) Especially for trait interfaces.

There are also nasty cases where you end up crashing randomly somewhere else in your code at runtime because somewhere something passed a List<Foo> and it expected a List<Bar>, but somewhere in between the type information got lost.

Ditto, I find myself wishing to be able to do instanceof T / T[] (that's an array of T) annoyingly often.

Look at the mess that is EnumMap for an illustration of why type erasure can be frustrating. The amount of reflection done at runtime for what should be (and is, if you write a non-generic implementation, or if you're using a language that's sane) purely compile-time work is... frustrating. (And while you're at it, the fact that you can even attempt to pass in a non-enum into EnumMap. I thought Java was supposed to try to push such errors into compile time?)

[slantedview]

> There's no (good) way of going "this is a Comparable<Foo> and a Comparable<Bar>, but not a Comparable<Baz>" that's detectable at run

It's a shame that various libraries/frameworks have resorted to building APIs around Type Tokens - where users have to create anonymous classes - to create something that effectively reifies some generic type information. It's a lame solution, but a solution.

[tel]

It's a dangerous solution as well given that it relies on user land extensible code to be correct in order to ensure type safety. Generally this is true whenever you have coercion, but type tokens done wrong give an (invalid!) excuse to coerce.