scala> class A defined class A scala> class B defined class B scala> val a: A = new A a: A = A@551510e8 scala> a match { | case _: B => println("unlikely") | case _ => println("no match") | } no match In the example above shouldn't the compiler tell me that one of the cases can never match? A slightly more complicated example recently caught me out, leading to what felt like an unnecessary bug that should have been caught by the compiler.Edit:Just to be clearer about the question. Is this impossible in Scala for some reason I can't see? (I can understand if the types were using generics and type erasure was causing problems but this looks pretty straight forward.) And if this is not impossible are there legitimate reasons this isn't in Scala? If not when will it be added? ;)
3 Réponses :
Le compilateur vous avertit (en fait la compilation échoue) si vous utilisez des classes de cas:
scala> case class A() defined class A scala> case class B() defined class B scala> val a = A() a: A = A() scala> a match { | case A() => println("A") | case B() => println("B") | case _ => println("_") | } <console>:13: error: constructor cannot be instantiated to expected type; found : B required: A case B() => println("B")
Malheureusement, les classes de cas ont des restrictions et ne sont pas toujours appropriées. Je ne vois pas pourquoi le compilateur ne peut pas comprendre cela pour les classes normales.
Actuellement, la vérification de l'exhaustivité et de la redondance ne sont effectuées que pour les modèles de constructeur de classe de cas. En principe, le compilateur pourrait également le faire pour d'autres types de motifs. Mais il faudrait être spécifié dans le SLS exactement quels tests sont effectués. Cela a l'air faisable mais non trivial, compte tenu des interactions entre différentes classes de motifs. Donc, en résumé, c'est l'un des domaines de Scala qui profiteraient d'autres contributions. P>
Incroyable ! Je vais ma réponse de celui qui m'a appris Scala et l'avouement aussi! Thx Stackoverflow!
J'ai vérifié dans Scala 2.13.3 Code>, nous obtenons un avertissement de
Test de type sans fruit code>: