Pattern Match with Default Case Cannot Be Optimized To Switch Statement

[adamgfraser]

Minimized code

import scala.annotation.switch

sealed trait Fruit

object Fruit {

  case object Apple extends Fruit
  case object Banana extends Fruit
  case object Orange extends Fruit
  
  def isCitrus(fruit: Fruit): Boolean =
    (fruit: @switch) match {
      case Orange => true
      case _      => false
    }
}

Output

// Could not emit switch for @switch annotated match since there are not enough cases

Expectation

I would have expected this to work as it appears to on Scala 2. I can understand that there are only two cases in the match statement versus three types of fruit but I would have hoped the compiler would be smart enough to know that using a wildcard is equivalent to matching against each of the remaining cases. If I enumerate them individually as in case Apple | Banana => ??? this works, but it doesn't seem like I should have to do that.

[smarter]

it appears to on Scala 2

Neither Scala 2 nor Dotty emit a tableswitch or lookupswitch for this code (which is what @switch checks for), they both just return Orange.equals(fruit) which is optimal.

If I enumerate them individually as in case Apple | Banana => ??? this works

That would be wrong, since this again won't emit a switch (because there's no reason to), but it doesn't appear to be true. I think you may have minimized that code sample too much: does the original actually match on objects or are you matching on integers?

[adamgfraser]

@smarter I think I may indeed have minimized too much. Here is another version:

import scala.annotation.switch

sealed trait Fruit {
  def tag: Int
}

object Fruit {

  case object Apple extends Fruit {
    val tag = 1
  }
  case object Banana extends Fruit {
    val tag = 2
  }
  case object Orange extends Fruit {
    val tag = 3
  }
  
  def isCitrus(fruit: Fruit): Boolean =
  (fruit.tag: @switch) match {
    case 3 => true
    case _      => false
  }
}

object Example extends App {
  println("Hello, World!")
}

The original code that generated the issue is here. Where we got an error like the above when we tried to compile this on Dotty.

[smarter]

This is intentional, we only emit a tableswitch instruction if there are at least four cases, otherwise we just use if/else, I assume this is for performance but I don't know how the exact value of 4 was arrived at, I would haany idea @odersky, @sjrd? I traced it to this commit: 2e7294c

[adamgfraser]

Hmmm, interesting. In the original example there are a total of seven cases but we want to treat four of them the same way as part of the default branch.

Maybe there needs to be some change in the warning message to better communicate this? Adding case a | b | c | d => ??? silences the warning which gives the impression that is more efficient but it seems like that is not the case and maybe is even less efficient? Maybe if the warning said something about switch statements not being used if there are fewer than four branches? It seems like in our actual code the thing we should be doing is just not using the switch annotation there but that isn't exactly obvious from the warning message.

[smarter]

Adding case a | b | c | d => ??? silences the warning which gives the impression that is more efficient but it seems like that is not the case and maybe is even less efficient?

It's probably less efficient yes.

Maybe if the warning said something about switch statements not being used if there are fewer than four branches?

I'm thinking maybe it just shouldn't say anything in this case. People don't really care about the exact instructions used on the JVM to represent the pattern match even if that's what the documentation of @switch mentions, they only care that it's efficient and they hope that putting an @switch asserts that.

[adamgfraser]

That makes sense to me.

[sjrd]

I'm thinking maybe it just shouldn't say anything in this case. People don't really care about the exact instructions used on the JVM to represent the pattern match even if that's what the documentation of @switch mentions, they only care that it's efficient and they hope that putting an @switch asserts that.

Yes, that is what the latest scalac does, IIRC. It used to emit a warning but I believe it's been changed over that specific concern.

[sjrd]

This is the scalac PR from 2015 that stopped emitting a warning in the same situation: scala/scala#4418

[odersky]

The scalac PR makes sense and should be adopted. We still should make sure that the warning is emitted for large pattern matches that cannot be turned into switches.