Hacker News Reader

I'm not quite sure that's due to type erasure. What would happen to this code if T were an interface? Meanwhile even though (AFAIK) GHC uses type erasure, you can do something like that and create values "de novo" if the typeclass supports it e.g. Alternative's `empty` or MonadPlus's `mzero`

View on HN

Even if you constrain the type to be something you know is a class, it won't work. [1]

The typical workaround in Java is to either pass around .class instances, or to do tricks with anonymous subclasses to create a type token. [2]

[1]: https://ideone.com/th18eh [2]: http://docs.guava-libraries.googlecode.com/git/javadoc/com/g...

> Even if you constrain the type to be something you know is a class, it won't work. [1]

Oh yes, I'm not saying it's possible to do this in Java, AFAIK you're right that it's not, I'm saying I'm not sure it's because of type erasure, at least type erasure on its own.

I think it is. As far as Java is concerned, T is Object in that context. It can't generate code for "allocate a T" because Foo only actually operates on Objects, not Ts. That is, there will be one version of Foo, and that version will generate code to interact with Objects, not Ts. It can't allocate a T because the type of T is erased from Foo. That is type erasure.

Reply on news.ycombinator.com