It really depends at what level -- because the erasure is done at the language level rather than the VM you _have_ to have a pile of runtime casts, even when those casts are no-ops :-/

I agree it works, i just don't think it's as elegant :D

Of course eventually everything is running on an untyped CPU and everything is just an integer so it's all erased in the end. Unless you have one of those silly mid-90s java cpus right?

Or maybe a LISP-machine

Well, that's a detail of how the VM works. My only point was that type erasure is not inherently bad, as plenty of languages do type erasure, like Haskell and OCaml. Of course you can always create conditions where it could become a problem.

But the example with C# "doing it right" is a little odd in that case, since Microsoft had the opportunity to build something new, that didn't have the same issues the JVM had. And they did, in some ways, but that doesn't mean tracking type parameters at the VM level is the only way to do it "right".

> silly mid-90s java cpus

They are still quite actual, here is one example.

http://www.imsystech.com/products/im3910-ic/

Even without full-blown reflection, the problem is that you don't have an "is instance of" operation for unerased types. Which is crucial to case/match as used in Scala and functional programming in general.

It is not crucial for functional programming, unless your functional programming language uses types as variant tags.

Both Haskell and OCaml use type erasure, and I doubt anyone would claim they aren't functional languages.

If they store a variant tag, that means they don't erase the bit of info that's needed for case matching. My point is that it's crucial to be able to tell at runtime to which (sub)type a value belongs. Other type information that isn't necessary for that can still be erased.

I think we're in agreement, and just tripping over terminology. In most functional languages, values in a variant are just values in that variant. They don't each have their own type, which means the variant tag isn't actually type information.

You can observe it on the JVM when you realise you can't overload a function with arguments that differ only in generic type.

Yes, my point was that there's nothing inherently wrong with type erasure. You can of course create conditions that would be problematic, like the design of Java and JVM does.