Pourquoi les variables ne sont-elles pas autorisées dans les modèles alternatifs ?

Question

Souvent, vous avez des correspondances "symétriques" et vous voulez écrire des choses comme :

def g(p:(Int,Int)) = p match {
  case (10,n) | (n,10) => println(n)
  case _ => println("nope")
}

Ceci n'est pas autorisé, mais si chaque alternative a les mêmes variables con les mêmes types Si vous n'êtes pas d'accord, cela ne devrait pas être un problème, car cela pourrait être traduit en cas séparés :

def g(p:(Int,Int)) = p match {
  case (10,n) => println(n)
  case (n,10) => println(n)
  case _ => println("nope")
}

Alors pourquoi avons-nous cette restriction ?

Answer 1

Probablement parce que cela prendrait du temps à mettre en œuvre et que ce temps est mieux utilisé ailleurs. Cela ajouterait aussi inutilement à la complexité du langage et de son compilateur. Comme vous l'avez déjà mentionné, le problème peut facilement être évité. Une autre façon d'éviter le problème est d'écrire un extracteur personnalisé :

object ThisOrThat {
  def unapply(p:(Int,Int)):Option[Int] = p match {
    case (10, n) => Some(n)
    case (n, 10) => Some(n)
    case _ => None
  }
}

Answer 2

Il semble que ce serait fastidieux à mettre en œuvre... Il y a un suggestion de fonctionnalité depuis longtemps.

Les solutions de contournement évidentes consistent à définir une fonction pour le résultat, et à l'appeler à partir d'une fonction distincte. case (mieux pour les motifs simples), ou de définir un extracteur personnalisé pour le motif alternatif, comme Kim l'a suggéré (mieux lorsqu'il est imbriqué dans un motif que vous préférez ne pas avoir à dupliquer).

Dans tous les cas, il est plus verbeux et plus difficile à lire que s'il était pris en charge par le langage, mais il faut espérer que quelqu'un finira par l'implémenter.