ここでScala2.13がパターンマッチングに不満を持っている理由を理解できません
trait A {
sealed trait T
case class TImpl() extends T
}
trait Fail[B <: A] {
val a: B // no error if `a: A`
def foo(t : a.T): Unit = t match {
case _: a.TImpl => // "match may not be exhaustive. It would fail on the following input: TImpl()"
}
}
合理的な回避策はありますか？Dottyで問題ないようです
原則としてパターンマッチングが完全ではない理由を知りたい場合は、たとえば次の例を参照してください。
trait A {
sealed trait T
case class TImpl() extends T
}
trait Fail[B <: A] {
val a: B
def foo(t : a.T): Unit = t match {
case _: a.TImpl =>
}
}
class B extends A
val b = new B
class FailImpl extends Fail[b.type] {
override val a: b.type = b
}
val fail: Fail[b.type] = new FailImpl
class C
case class CImpl() extends C with b.T
val x = CImpl()
fail.foo(x) // MatchError
実際にはなかったと言えますC。まあ、コンパイラはそれを理解するのに十分賢いはずです。
警告をオフにしたい場合は、次のように書くことができます。 @unchecked
def foo(t : a.T): Unit = (t: @unchecked) match {
case _: a.TImpl =>
}
仕様によると、
パターン一致のセレクターが封印されたクラスのインスタンスである場合、パターン一致のコンパイルは、特定のパターンのセットが網羅的ではない、つまり
MatchError実行時に発生する可能性があることを診断する警告を発行できます。
https://scala-lang.org/files/archive/spec/2.13/08-pattern-matching.html#pattern-matching-expressions
コンパイラは警告を出すことができますが、そうしなければなりません。したがって、警告がないからといって、パターンマッチングが完全であるとは限りません。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加