Union of function types leads to ClassCastException

[Jasper-M]

I don't know why or how, but:

scala> val f: (Int => Int) | (String => Int) = (a: Int) => a + 3                
val f: (Int => Int) | (String => Int) = Lambda$1427/1583001542@5583098b

scala> f(5)                                                                     
val res0: Int = 8

scala> f("c")
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
	at scala.runtime.BoxesRunTime.unboxToInt(BoxesRunTime.java:101)
	at scala.compat.java8.JFunction1$mcII$sp.apply(JFunction1$mcII$sp.java:12)

[Jasper-M]

Variance and library free example:

scala> abstract class A[B] { def foo(b: B): B }
// defined class A

scala> class AInt extends A[Int] { def foo(b: Int) = b + 1 }
// defined class AInt

scala> val a: A[Int] | A[String] = new AInt
val a: A[Int] | A[String] = AInt@47fb7ec9

scala> a.foo(3)
val res9: Any = 4

scala> a.foo("bar")
java.lang.ClassCastException

[jducoeur]

What should this do? Frankly, a ClassCastException is pretty much what I'd expect. This strikes me more as a spec issue than anything else...

[Jasper-M]

Honestly I don't know... But a ClassCastException should never be the expected behavior for code that doesn't contain explicit casts imho.

[smarter]

A ClassCastException means that we have a soudness bug, we want this kind of things to be detected at compile-time, not runtime. Here's a minimization:

class Foo[A] {
  def foo(a: A): Unit = {}
}

object Test {
  def main(args: Array[String]): Unit = {
    val x: Foo[Int] | Foo[String] = new Foo[Int]
    x.foo("") // Should not compile !
  }
}

Here, the compiler assigns (a: Int | String): Unit as the type signature of x.foo, which is clearly wrong. Because we're in contravariant position this should at least be (a: Int & String): Unit but I'm not 100% sure that's good enough given that Foo is invariant in A, the more radical approach would be to simply disallow any call to foo on x because of its type.

[sjrd]

Easy. The parameter should be typed as Int & String, not Int | String. That's it. If the actual argument is known to be an instance of all types, then it won't matter what particular function is called (the one taking an Int or the one taking a String), it will happily accept the value of type Int & String.

[odersky]

@srjd Yes, that's about it. The reason why it did not do this is and how to fix it was quite tricky, though.