<@U0DNLV6RX> Erasure is a much better alternative ...

# random

[cedric]

@hoang Erasure is a much better alternative than reification: http://beust.com/erasure

[bmsantos]

@cedric, i would like to have reification as an "option" for projects where it is actually useful. Fantom has it and apparently they work quite well. Just a different philosophy though.
http://fantom.org/forum/topic/1581

[cedric]

Define "works well"...

[cedric]

It still suffers from all the downsides, eg problematic interop

[bmsantos]

Yes, but that interoperability loss is mainly due to the Java byte code "limitation".

[bmsantos]

Both approaches suffer from downsides. That's why I stated that it would be great to be able to "plugin" reification when deemed necessary.

[cedric]

@bmsantos No, the limitations of reification are much deeper than the Java byte code alone. A lot more type information has to be kept around, which is what strains writing type systems on reified platforms

[bmsantos]

Correct. Java byte code has no way to easily keep generics type information. That was my point.

[cedric]

@bmsantos It's not just that. Even if Java byte code had this ability, the overhead and extra code you need to write to implement these type systems is daunting and produces unusable solutions. Scala.net was abandoned for this very reason.

[cedric]

It is possible to port sophisticated type systems to a reified platform. It's just so much work that it's not worth it. Scala.net learned this the hard way.

[bmsantos]

I understand that. Kotlin was also initially on the same boat. I even remember highly versed Scala folks stating that Kotlin would most probably not be able to fulfill this promise. Scala might have the most complex type system to date, so no surprise that supporting reified types would be a giant and complex task. Ceylon, for example, implements it as well, but again, at the cost of interop.

[groostav]

so the main arguments against complete runtime reification of generic types is that its A) hard to implement and B) would break existing code?

I feel like a lack of reification on the kotlin.Function<> and java.function.Function types (and, of course, collections) is a real travesty.

[bmsantos]

@groostav, It doesn't break existing code, it breaks Java bytecode compatibility. The fact that Kotlin is bytecode compatible with Java is much more important to me than having reified generics. Also means leaner bytecode. if I can only have one, then I rather have erasure.

[cedric]

@groostav The JVM could have had reified generics without breaking backward compatibility, not sure why so many people are convinced of the reverse. This is not the main reason why erasure was picked. My blog post linked above gives a list of reasons