Pourquoi la méthode orNull de l'option ont cet argument implicite superflu?

Question

Je me demande quelle est la raison de la (implicit ev: Null <:< A1) ici:

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

ne serait pas

def orNull[A]: A = this getOrElse null

être assez considérant qu'il ne semble même pas travailler avec les types de valeurs comme

Option(1).orNull

Option(1).getOrElse(null)

fait?

Code de Option source

Answer 1

Tous les types de scala peuvent être nuls. En particulier, tout a deux enfants, et AnyRef AnyVal. AnyRef peut gérer les types de null. types AnyVal pourraient être primitives sur la machine virtuelle Java et ne peuvent donc pas être nul. L'implicite est un type contrôle différé qui permet l'option [chaîne] à utiliser orNull mais pas l'option [Int].

Note: Cette dichotomie Int étant en boîte / objet Unboxed / primitive a des manifestations très étranges à Scala, comme 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
                                           ^

Alors, null n'est pas un type acceptable pour tous A, seulement pour les nullables. Les sous-classes de AnyVal sont des exemples typiques de types non-nullable. En l'absence de ce paramètre, il est impossible d'écrire cette méthode.