Scala pattern match non è esaustivo su classi case annidate

Question

Ho una gerarchia di caso di classe per codificare alcuni di richiesta e di elaborazione errori:

sealed trait OpError 
    sealed trait RequestErrorType 
    sealed trait ProcessingErrorType 

    final case class InvalidEndpoint(reason: String) extends RequestErrorType 
    final case class InvalidParameters(reason: String) extends RequestErrorType 

    final case class InvalidFormat(response: String) extends ProcessingErrorType 
    final case class EntityNotFound(id: Long) extends ProcessingErrorType 

    final case class RequestError(errorType: RequestErrorType) extends OpError 
    final case class ProcessingError(errorType: ProcessingErrorType) extends OpError 

Se scrivo un semplice incontro in tutti i modelli:

def printMatches(error: OpError): Unit = error match { 
    case RequestError(InvalidEndpoint(reason)) => //print something 
    case RequestError(InvalidParameters(reason)) => //print something 
    case ProcessingError(InvalidFormat(format)) => //print something 
    case ProcessingError(EntityNotFound(entityId)) => //print something 
    } 

il compilatore mi dà un avvertimento circa partita mancante:

match may not be exhaustive. 
It would fail on the following input: ProcessingError(_) 
def printMatches(error: OpError): Unit = error match { 

Ma ProcessingError prende in un P rocessingErrorType con solo due estensioni: InvalidFormat e EntityNotFound, entrambe le quali sono contabilizzate nella corrispondenza del modello. Cosa mi manca?

Ancora più curioso è che se cambio il tipo di parametro di InvalidParameters o InvalidEndpoint ad una stringa *, non ottengo l'errore:

final case class InvalidParameters(reason: String*) extends RequestErrorType 

Tutte le idee?

Answer 1

Questo è un bug confermato. I filed a bug report for this ed è stato fissato per Scala 2.12.0-M4.

Answer 2

si può aiutare il compilatore con un'annotazione incontrollato:

... = (error: @unchecked) match ... 

ma si dovrebbe essere sicuri, il tuo partner è esaustivo.

Answer 3

Penso che la corrispondenza di esaustività funzioni su un singolo livello di ereditarietà. RequestErrorType e ProcessingErrorType fanno parte del costruttore in cui tale esaustività non viene controllata.

È possibile vederlo dalla lettura del codice, ma sembra che il compilatore non lo faccia.

Answer 4

Molto interessante! Sfortunatamente, non ho trovato una risposta. Sto girando intorno allo http://www.scala-lang.org/files/archive/spec/2.11/08-pattern-matching.html#constructor-patterns ma non ho trovato una spiegazione valida per quello che sta succedendo.

Ecco una demo più semplice (spero che non ti dispiaccia):

sealed abstract class ClassOne 
case class ClassOneImpl() extends ClassOne 

sealed abstract class ClassTwo() 
case class ClassTwoImpl() extends ClassTwo 

sealed abstract class Foo 
case class FooOne(x: ClassOne) extends Foo 
case class FooTwo(x: ClassTwo) extends Foo 

def printMatches(st: Foo): Unit = st match { 
    case FooOne(ClassOneImpl()) => println() 
    case FooTwo(ClassTwoImpl()) => println() 
} 

ho osservato che ciascuno dei seguenti due modifiche rimuove l'avvertimento:
1) Modifica FooOne e FooTwo firme in modo che invece di prendere ClassOne e ClassTwo prendono ClassOneImpl e ClassTwoImpl
2) Rimozione FooOne o FooTwo modo che ci sia una sola classe case estendentesi Foo (che porta t o un solo caso nel pattern matching).

Forse potremmo inviare un problema e vedere cosa dicono?