Почему переменные не допускаются в альтернативных шаблонах? - PullRequest
16 голосов
/ 03 июля 2011

Часто у вас есть "симметричные" совпадения и вы хотите написать что-то вроде:

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

Это недопустимо, но если каждая альтернатива имеет одинаковые переменные с те же типы , это не должно быть проблемой, так как это может быть переведено в отдельные случаи:

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

Так почему у нас есть это ограничение?

Ответы [ 2 ]

21 голосов
/ 03 июля 2011

Скорее всего, потому что это займет некоторое время, а лучше потратить его в другом месте. Это также излишне увеличило бы сложность языка и его компилятора. Как вы уже упоминали, проблему можно легко избежать. Еще один способ избежать этой проблемы - написать собственный экстрактор:

object ThisOrThat {
  def unapply(p:(Int,Int)):Option[Int] = p match {
    case (10, n) => Some(n)
    case (n, 10) => Some(n)
    case _ => None
  }
}
0 голосов
/ 08 сентября 2016

Похоже, это было бы утомительно для реализации ... Есть предложение о функции с самого начала.

Очевидные обходные пути: либо определить функцию для результата и вызвать ее из отдельных case s (лучше для простых шаблонов), либо определить собственный экстрактор для альтернативного шаблона, как предложил Ким (лучше, когда он вложен в шаблон, который вам не нужно дублировать).

В любом случае, в конечном итоге он становится более многословным и более трудным для чтения, чем если бы он был поддержан языком, так что, надеюсь, кто-то в конечном итоге это осуществит.

...