Question: type erasure for features that require CLR changes?

[leandromoh]

There are lot of features that are complicate to add to language because CLR does not support (at least is what I understood of what I have read) like type classes, higher kinded types, union intersection types, etc.

My question is: could this kind of feature be implemented using type erasure? What are the tradeoffs?
Of course reflection stuff would not work as expected if using type erasure, at least not natively.
F# for example has the FSharp.Reflection namespace with type helpers to translate runtime types to something meaningful for the language context.

[huoyaoyuan]

C# is designed to be close to CLR features. Type erasure shouldn't be considered.

Moreover, the design of C# focuses on performance more and more now.

[leandromoh]

C# is designed to be close to CLR features.

any special reason why?

Moreover, the design of C# focuses on performance more and more now.

Does type erasure have worst performance?

[AartBluestoke]

Moreover, the design of C# focuses on performance more and more now.

People implementing these features without the assistance of the runtime results in worse performance than if certain features had builtins.

[cheong00]

Type erasure is my worst headache when maintaining Java code. (Say, people writing APIs that returns different "Order" array which the only common field is "ID")

And then there are companies with policy that you should fix all warnings and must not suppress them. People are going to pull their hair real hard as there are cases where there simply no way to properly fix it.

So please, don't ever consider implement it. Even people coding Java for living complains it is the worst decision to implement generics with type erasure.

[leandromoh]

I personally dont like type erasure. it is amazing to have all runtime types as expected. just trying understood the trade offs

[theunrepentantgeek]

If you read up on the history of C# Generics, introduced in C# 2.0, you'll find that they were originally going to be implemented by type erasure (yes, really!).

Fortunately, some of the smart folks from Microsoft Research were able to successfully lobby for generics to be deeply wired into the CLR, resulting in the superior implementation we enjoy today.

Having the CLR fully aware of generics allows the JIT compiler to do some very smart things with optimization, increasing the speed of operation and, in some cases, reducing the memory footprint.

One of the defining features of the C# language is the way that features are fully baked - they take the time to consider the implications of changes and put in the effort to ensure that everything works together in satisfactory ways.

I don't believe type erasure is a good approach - it gives you a good fraction of the benefits, but at the cost of forever depriving you of the rest. For just one example, I don't believe LINQ would have been invented without CLR support for generics, and I suspect async/await would be the same.