isInstanceOf is statically optimized away based on compiler knowledge about types

[valenterry]

The isInstaceOf check are optimized away in the following situation:

    class A
    trait T
    
    val casted: A with T = (new A).asInstanceOf[A with T]
    casted.isInstanceOf[A with T] // = true

However:

    casted.isInstanceOf[A] // = true
    casted.isInstanceOf[T] // = false

(fiddle: https://scalafiddle.io/sf/rjfApD5/0)

The check is optimized away and replaced with true. I am not sure if that is a bug or maybe even desired (optimization) behaviour. However, when using isInstanceOf I would intuitively have expected a runtime-check no matter what the compiler statically knows.

In any case I would expect the test for T and for A with T to both give the same result, be it true or false.

I could reproduce this in both scala 2.11.8 and 2.12.1.

[lrytz]

I don't think there's a bug here.

You cannot cast to A with T: a cast is a run-time type check, but there's not run-time type representing A with T. What happens ist that the Scala compiler erases A with T to A, so you end up with (new A).asInstanceOf[A], which obviously passes. With -Xprint:erasure

scala> class A; trait T
scala> val a = new A
scala> a.asInstanceOf[A with T]
[[syntax trees at end of                   erasure]] // <console>
...
        private[this] val res1: A = $line5.$read.$iw.$iw.a().$asInstanceOf[A]();

scala> a.asInstanceOf[T]
java.lang.ClassCastException: A cannot be cast to T

The same is true for the casted.isInstanceOf[A with T] check, it gets erased to casted.isInstanceOf[A].

What would be useful here is a compiler warning when a type argument of asInstanceOf / isInstanceOf cannot be represented at run time.

[sjrd]

What would be useful here is a compiler warning when a type argument of asInstanceOf / isInstanceOf cannot be represented at run time.

Not for asInstanceOf! There are zillions of cases where you cast and the target type is not entirely checked, including many compiler-generated ones. Issuing warnings for such cases is not practical.

However, isInstanceOf[A with T] should even be a compile-time error, because the compiler cannot (or at least does not) compile it correctly, giving you a wrong result. There is no use case for this.

For example, in Scala.js, when Foo is a JavaScript trait, x.asInstanceOf[Foo] is erased, but x.isInstanceOf[Foo] is a compile error, instead of blindly returning true which is never useful.

[lrytz]

Good points, thanks @sjrd

[valenterry]

Yes, you cannot cast it at runtime. But there is a use case for it at compiletime for tagging types. See for example: https://github.com/milessabin/shapeless/blob/master/core/src/main/scala/shapeless/typeoperators.scala

So, yes, a.asInstanceOf[A with T] will not change the runtime value, but it will in fact change what the compiler knows (or thinks to know) about the type.

If casted.isInstanceOf[A with T] gets erased to casted.isInstanceOf[A with T] then what about casted.isInstanceOf[T]?

[lrytz]

what about casted.isInstanceOf[T]

This cast can be checked, T exists at run-time, it's an interface.

[valenterry]

I see. So casted.isInstanceOf[A with T] is always the same as casted.isInstanceOf[A]. Thanks for the clarification.

[smarter]

I see. So casted.isInstanceOf[A with T] is always the same as casted.isInstanceOf[A]. Thanks for the clarification.

No. isInstanceOf is much more magic than asInstanceOf, isInstanceOf[A with T] will be rewritten to isInstanceOf[A] && isInstanceOf[T] by the compiler:

class A
trait T

object Test {
  def foo(x: Any) = {
    x.isInstanceOf[A with T]
  }
}

[[syntax trees at end of                       jvm]] // isInstance.scala
package <empty> {
  class A extends Object {
    def <init>(): A = {
      A.super.<init>();
      ()
    }
  };
  abstract trait T extends Object;
  object Test extends Object {
    def foo(x: Object): Boolean = x.$isInstanceOf[A]().&&(x.$isInstanceOf[T]());
    def <init>(): Test.type = {
      Test.super.<init>();
      ()
    }
  }
}

From the spec, chapter 12:

The type test x.isInstanceOf[T] is equivalent to a typed pattern match

and again from the spec, chapter 8:

A compound type pattern T1 with … with Tn where each Ti is a type pattern. This type pattern matches all values that are matched by each of the type patterns Ti.:

What happens in your original example is that the compiler optimises out the isInstanceOf[A with T] check to true based on its knowledge of static types, but it fails to take into account that having a static type of A with T does not mean that isInstanceOf[A] && isInstanceOf[T] will always be true due to erasure. I would consider this a bug.

[valenterry]

I will reopen and let you guys decide. ;)

[lrytz]

Thanks @smarter, nice, I wasn't aware!

To summarize the issue:

scala> class C; trait T
scala> val a = new C

scala> a.isInstanceOf[C with T]
res0: Boolean = false

scala> a.asInstanceOf[C with T].isInstanceOf[C with T]
res1: Boolean = true

It's consistent with type patterns:

scala> a match { case _: C with T => true; case _ => false }
res2: Boolean = false

scala> a.asInstanceOf[C with T] match { case _: C with T => true; case _ => false }
res3: Boolean = true

Not sure this is a bug. It requires a cast to get in such a situation, and I don't know what kind of behavior is guaranteed / allowed after casting. cc @adriaanm

[adriaanm]

Haha, cool! Agreed that we shouldn't constant fold a.asInstanceOf[C with T].isInstanceOf[C with T] to true, but it's also true we don't guarantee much once you start casting.

For the pro-bug case, it's the same as

scala> class A
defined class A

scala> class B
defined class B

scala> (new A).asInstanceOf[B].isInstanceOf[B]
java.lang.ClassCastException: A cannot be cast to B
  ... 29 elided

(except that, as explained, you get away with casting to C with T)

[lrytz]

we shouldn't constant fold a.asInstanceOf[C with T].isInstanceOf[C with T] to true

Where would you draw the line? Which assumptions can we make about the correspondance of static and dynamic types, and which not?