¿Por qué la Opción del orNull método superflua argumento implícito?

Question

Me pregunto cuál es la razón por 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

def orNull[A]: A = this getOrElse null

ser suficiente teniendo en cuenta que ni siquiera se parecen a trabajar con los tipos de valor como

Option(1).orNull

pero

Option(1).getOrElse(null)

¿?

Option's código fuente

Answer 1

No todos scala tipos puede ser null.En particular, todo tiene dos hijos, AnyRef y AnyVal.AnyRef puede manejar tipos nulos.AnyVal tipos podría ser primitivos en la JVM y por lo tanto no puede ser null.El implícito es un retraso en el tipo de verificación que permite la Opción[Cadena] para utilizar orNull pero no la Opción[Int].

Nota:Esta dicotomía de Int estar en caja/sin caja de objeto/primitiva tiene muy extrañas manifestaciones en la Scala, tales como null.asInstanceOf[Int] == 0 // verdadero.

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
                                           ^

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