Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't think either of your points has anything to do with type erasure, and everything to do with allowing generics to take value types. This was an easy decision in Java, since it doesn't (yet?) allow user-defined value types. But C# has had `struct` since the beginning.

C# creates one instance of a generic for all reference types. The general consideration in instantiating multiple versions is object size. All reference types are the same size, so not a concern. Value types, however, range wildly in size and so generally get their own specialized versions during code generation.

The same choice effects the ability to wildcard. C# probably could implement wildcards over reference types, but it would feel inconsistent without value types. And, honestly, a good portion of wildcarding in my experience is to handwave away the compiler when you know what you're doing without reified types. Simply not an issue in C# -- its stronger guarantees around generic types means I can make that same code generic over the type I'm wildcarding in Java.



Code generation is definitely important to talk about, but that really wasn't the focus of my first example. Even if Foo and Bar were both reference types, the same reasoning would apply.

In C#, you can do:

    class MyClass : IList<Foo>, IList<Bar> { ... }
In Java, you can't do:

    class MyClass implements List<Foo>, List<Bar> { ... }
I know this is commonly viewed as an annoying restriction, but, IMO, it's rather an indication that you're writing code that doesn't respect the contract of the generic interface. For example, what should the `Count` property return if you're implementing IList<T> twice? (C# wiggles around this with explicit interface implementations, but I think it's fair to argue that that's not a strictly superior approach to Java's).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: