scala - una - ¿Por qué el método Opción o No tiene este argumento implícito superfluo?

superfluo etimología

Question

Me pregunto cuál es el motivo de la (implicit ev: Null <:< A1) aquí:

sealed abstract class Option[+A] extends Product with Serializable {
def orNull[A1 >: A](implicit ev: Null <:< A1): A1 = this getOrElse null
...
}

No lo haría

def orNull[A]: A = this getOrElse null

sea ​​suficiente teniendo en cuenta que ni siquiera parece funcionar con tipos de valor como

Option(1).orNull

pero

Option(1).getOrElse(null)

¿hace?

Código fuente de la Option

Answer 1

No todos los tipos de scala pueden ser nulos. En particular, Any tiene dos hijos, AnyRef y AnyVal. AnyRef puede manejar tipos nulos. Los tipos AnyVal pueden ser primitivos en la JVM y, por lo tanto, no pueden ser nulos. Lo implícito es una verificación de tipo demorada que permite que Option [String] use o No, pero no Opción [Int].

Nota: Esta dicotomía de que Int es un objeto / primitiva en caja / sin caja tiene manifestaciones muy extrañas en Scala, como null.asInstanceOf [Int] == ​​0 // true.

Answer 2

scala> abstract class Op[A] {
| def getOrElse(b: A): A
| def orNull[A]: A = this getOrElse null
| }
<console>:14: error: type mismatch;
found : Null(null)
required: A
def orNull[A]: A = this getOrElse null
^

Entonces, null no es un tipo aceptable para todos los A , solo para los que aceptan null . Las subclases de AnyVal son ejemplos típicos de tipos que no AnyVal . En ausencia de ese parámetro, no es posible escribir este método.