Unexpected type erasing using higher-kinded type & currying

[y-yu]

reproduction steps

using Scala 2.13.4

• Whole PoC code is https://gist.github.com/y-yu/2c5ff872b22acde4e1b3685a8ae015e8

  • Execute sbt run after download the files

• There is a type erasing difference between two classes: B1 and B1

  package example
  
  trait A[B[_]]
   
  class B1(x: String, y: A[List])
  class B2(x: String)(y: A[List])

  • class B2 defined to take two parameters as multiple parameter lists

• Their javap results are:

  $ javap target/scala-2.13/classes/example/B1.class 
  Compiled from "Main.scala"
  public class example.B1 {
    public example.B1(java.lang.String, example.A<scala.collection.immutable.List>);
  }
   
  $ javap target/scala-2.13/classes/example/B2.class 
  Compiled from "Main.scala"
  public class example.B2 {
    public example.B2(java.lang.String, example.A<?>);
  }

  • In B2 constructor, the type of the second argument is the erasured type: A<?>

• We expect that B1 and B2 should be the same result

problem

• We found this bihavior using Google Guice
  • Needless to say, it's very popular library
  • We use this for Play framework
• This behavior is not good for DI wiring higer-kinded classes by Guice
  • We cannot use currying constructor if the constructor takes higher-kinded type arguments such like Monad instance
  • Since using Guice DI, we have to inject only our classes but also implicit parameters 😢
• So we wish to resolve this bihavior 🙏

postscript

• We pass the higher-kinded type parameter like this:

  class B3[F[_]](x: String)(y: A[F])

  • It's OK 🙆‍♀️ but I don't know why it was not erased 🤔

  $ javap -c example.B3
  Compiled from "Main.scala"
  public class example.B3<F> {
    public example.B3(java.lang.String, example.A<F>);
  }

• @xuwei-k san tried it out in Scala3.0.0-M1

  $ javap target/scala-3.0.0-M1/classes/example/B1.class 
  Compiled from "Main.scala"
  public class example.B1 {
    public example.B1(java.lang.String, example.A<scala.collection.immutable.List<java.lang.Object>>);
  }
   
  $ javap target/scala-3.0.0-M1/classes/example/B2.class 
  Compiled from "Main.scala"
  public class example.B2 {
    public example.B2(java.lang.String, example.A<scala.collection.immutable.List<java.lang.Object>>);
  }

  • Why is java.lang.Object inserted as their type arguments? 🤔
  • Anyway both cases don't work well in Scala3.0.0-M1
  • Would it be better to report this to dotty repo too?

[joroKr21]

#7932, scala/scala#3550
The difference between List and [+A]List[A] which are otherwise equivalent 😢

[joroKr21]

https://github.com/scala/scala/blob/2.13.x/src/reflect/scala/reflect/internal/transform/UnCurry.scala#L53-L61
packSymbols -> existentialAbstraction -> normalize -> etaExpand

[joroKr21]

My take on this is that it was not intended to be supported and class B1(x: String, y: A[List]) works by accident.

[y-yu]

class B1(x: String, y: A[List]) works by accident

Oh... 😇 That's a bad news to me 😢

[joroKr21]

See #4337 and #4337 (comment):

I think we need to suppress signatures altogether for files with higher-kinded types.
They are conflated with raw types, and scalac will get confused.

It seems that this was never implemented. Would be interesting to see what happens in dotty.

[SethTisue]

The bigger change Martin suggested on 4337 seems too disruptive to be considered for Scala 2.

Even if, as Georgi says, B1 works "by accident", I think we could plausibly consider a PR that made B2 be handled the same as B1. It's just crazy that they don't have the same bytecode signature.

However, even if we accepted such a PR, that would not obligate Scala 3 to follow our lead. So perhaps such a PR isn't worth the bother.

[SethTisue]

Another possible future here is that you convince Scala 3 to do.... something, and then once that was merged, we could consider to what extent aligning with it in Scala 2 would be practical.