Estoy adivinando aquí ya que no soy un experto en scala, pero de acuerdo con documentation para la clase Any en scala, estoy pensando que dado que null no es un objeto, no deriva de Any y como tal no coincide con el primer caso enumerado.
Agregando el siguiente ejemplo de código. Imprime "algo más" cuando se ejecuta.
val x = (2, null)
x match {
case (i:Int, v:Any) => println("got tuple %s: %s".format(i, v))
case (i:Int, null) => println("something else %s".format(i))
case _ => println("catch all")
}
Después de más investigación que parece nula debe coincidir con algún sentido del documentation dice que se extienda AnyRef que se extiende Cualquier.
EDITAR: Como todos los demás han dicho. El primer caso no coincide nulo a propósito. Está especificado en la documentación.
Supongo que una de las razones de esta elección es que coincide con el comportamiento del bytecode "instanceof" en la JVM. –
Eso, y dejar que la nulidad desapareciera por completo. ¡Debes tener una tolerancia nula y obscena para buscar motivaciones! – extempore
"Tolerancia nula obscena" o no, existe un argumento de que el significado más natural y sencillo para un patrón de tipo "x: T" es hacer coincidir cualquier miembro de tipo T. Por ejemplo, evitaría irregularidades como "val x: Any = null "- bien, pero" val (x: Any, y: Any) = (null, null) "- MatchError. Eso "mata por completo" también. No estoy diciendo que Scala tomó la decisión equivocada, ni que sea particularmente importante dado que la idiomática Scala evita el uso de nulo. –