6 ms·

Disagree. Type erasure is actually one of th best possible decisions made by the java designers. Languages that have higher kinded types (Haskell, Scala)are vi

• mruts 7y ago
  Could you elaborate? How does type erasure relate to HKT?
  • viraptor 7y ago
    Yup, that doesn't seem to be a real restriction. Here's a comment on a roslyn issue for dotnet: https://github.com/dotnet/roslyn/issues/2212#issuecomment-98500288 https://github.com/dotnet/roslyn/issues/2212#issuecomment-98... > Of course it could be implemented type-erased style, but that's an unpleasant can of worms. > If it were implemented like C++ templates, it would be a source level feature, meaning you can't have higher kinded polymorphic methods in assemblies. I think we can reach consensus that such a feature would only pollute the language. > If it were implemented like Java generics, it would lead to all sorts of nonsense. For example you couldn't do typeof(M<>) inside the hkpm, since the type has been erased. And then a complex-but-good implementation idea follows. Type erasure is not necessary in this case.
    • zzygan 7y ago
      The complexity is exactly is issue. So while it’s possible to implement on the .net runtime without type erasure, it’s hard. Plus the only reason type erasure is bad is if you want reflection. Which in FP languages with a solid type system isnt idiomatic and safe anyway. Edit: value types are one other reason for not using erasure but Can be done other ways
• jimmaswell 7y ago
  I don't see how the absence of type erasure could possibly be a restriction. Cast everything to object if you must. I've literally never run into a situation where I wished type erasure was there but didn't have it, but I've ran into situations where type erasure caused problems in Java and where the absence of type erasure let me do things the way I wanted in C#. typeof(T), new T[], new T(), default(T), etc.
  • lazulicurio 7y ago
    > I don't see how the absence of type erasure could possibly be a restriction. Cast everything to object if you must. Erasure can be nicer than casting to object everywhere, especially when dealing with interfaces. It means you don't have to define separate interfaces for the erased and specialized cases. e.g. in Java, implementing List<T> means you also implement List. Meanwhile, in C#, you have to implement both IList and IList<T> if you want to be able to use a collection in an erased context (and even then, the interfaces don't provide exactly the same functionality). Implementing both IList<T> and IList<object> isn't much of an improvement. > I've literally never run into a situation where I wished type erasure was there but didn't have it, but I've ran into situations where type erasure caused problems in Java and where the absence of type erasure let me do things the way I wanted in C#. typeof(T), new T[], new T(), default(T), etc. IMO most of these aren't too bad to work around. Although, sometimes erasure can cause problems with reflection and you have to use Guava's TypeToken or something similar. One definite problem with erasure is that it doesn't play nice with unboxed value types.
    • jimmaswell 7y ago
      The codebase I work with has base classes like Thing, then Thing<T> : Thing, with the parts that don't need the T going in Thing.
      • lazulicurio 7y ago
        Sure, good interface design can ease things, but it doesn't really solve the problem I'm talking about. In Java, List<Foo> and List<Bar> are the same interface. In C#, IList<Foo> and IList<Bar> are different interfaces that just happen to have similar properties/methods. This means, in Java you can do Object obj = ... List<?> lst = (List<?>) obj Object item = lst.get(3) Whereas, in C#, to do something similar, you have to dynamically compile at runtime a specialization of a generic delegate.
        • jimmaswell 7y ago
          You can cast to plain IList and it works as expected. You can even use Add on it. https://dotnetfiddle.net/jcjchk https://dotnetfiddle.net/jcjchk