Antwort.

Geschichte der Frage

Pattern Matching ist einer der wichtigsten Sprachmechanismen in Rust, der aus funktionalen Sprachen stammt. Es ermöglicht die deklarative, prägnante und sichere Behandlung komplexer Wertvarianten, auch durch zusätzliche Bedingungen (Guard-Ausdrücke), was Flexibilität und Kontrolle über die Logik gibt.

Problem

Ohne Exhaustiveness Checking (Überprüfung der vollständigen Berücksichtigung aller Varianten) kann ein Teil der Leistungsfähigkeit von Pattern Matching fehlerhaft implementiert werden. Zudem kann man ohne Verständnis der Reihenfolge der Zweige und der Guard-Ausdrücke sowohl in der Logik als auch in der Performance Fehler machen.

Lösung

In Rust überprüft der Compiler, dass alle Varianten eines Enums (oder einfacherer Pattern-Strukturen) behandelt werden, oder dass ein Zweig _ vorhanden ist. Der Zweig kann außerdem durch einen Guard-Ausdruck (if nach dem Pattern) eingeschränkt werden, und nur wenn die Bedingung erfüllt ist, "trifft" er ein. Übrige Varianten werden nicht erfasst. Die Reihenfolge der Zweige ist wichtig: sie werden von oben nach unten überprüft.

Beispielcode:

enum Message {
    Hello,
    Data(i32),
    Quit,
}

fn handle(msg: Message) -> &'static str {
    match msg {
        Data(n) if n > 10 => "Big Data",
        Data(_) => "Some Data",
        Hello => "Greet!",
        Quit => "Bye",
    }
}

Wichtige Merkmale:

Sicherheit durch Exhaustiveness Checking: der Compiler lässt keine Fälle aus (oder zwingt dazu, explizit '_' zu verwenden).
Möglichkeit, Guard zu verwenden, um die Verarbeitungsbedingungen zu erweitern.
Die Zweige werden der Reihenfolge nach von oben nach unten überprüft, das erste übereinstimmende Pattern+Guard tritt in Kraft.

Fangfragen.

Tritt der Zweig mit Guard ein, wenn das Pattern übereinstimmt, aber die Bedingung nicht erfüllt ist?

Nein, in diesem Fall wird zur nächsten passenden Branche gewechselt. Pattern + Guard ist ein atomarer "Filter"; nur wenn beide übereinstimmen, wird der Körper des Zweigs ausgeführt.

Beeinflusst die Reihenfolge der Zweige im Match die Performance?

Ja. Besonders bei einer Vielzahl ähnlicher Patterns mit Guard: Der Compiler überprüft die Zweige von oben nach unten, was die Geschwindigkeit der Überprüfung zur Laufzeit beeinflusst – häufiger vorkommende Werte sollten früher verarbeitet werden.

Kann man Exhaustiveness Checking umgehen, indem man nur den Zweig _ setzt?

Technisch ja — das ist erlaubt, aber es geht Zuverlässigkeit verloren: Wenn der Typ neue Elemente ausschließt (oder hinzufügt), warnt der Compiler nicht vor nicht berücksichtigten Fällen. Es ist besser, immer wichtige Fälle explizit zu behandeln und "_" nur im Extremfall zu verwenden.

Typische Fehler und Anti-Patterns

Verwendung von Guard ohne das Bewusstsein, dass das Pattern angeblich übereinstimmt, aber die Bedingung nicht durchgeht: nicht berücksichtigte Fälle.
Ignorieren der Reihenfolge der Zweige bei mehrdeutigen Patterns, falsche Logik.
Man sollte immer Enums exhaustively behandeln und nicht alles in "_" stecken.

Beispiel aus dem Leben

Negativer Fall

Ein Match-Code für ein Enum mit Guard-Ausdrücken, bei dem das Pattern mit Guard zuletzt kommt, aber die meisten Werte direkt über den frühen Zweig _ verarbeitet werden und die notwendige Verarbeitung nie erreicht wird.

Vorteile:

Schnelle Implementierung eines "Stopfens" in Form von _.

Nachteile:

Logik funktioniert nicht, wichtige Werte werden nicht erfasst, und der Code ist schwer zu testen.

Positiver Fall

Zuerst werden die häufigsten und wichtigsten Varianten (mit Guard) aufgezählt, dann werden die übrigen exhaustively behandelt — ohne überflüssigen Code in "_".