Antwoord.

Geschiedenis van de vraag

Patroonmatching is een van de belangrijkste taalkundige mechanismen in Rust, afkomstig uit functionele talen. Het stelt je in staat om declaratief, beknopt en veilig complexe waardevarianten te analyseren, ook met behulp van aanvullende voorwaarden (guard-expressies), wat flexibiliteit en controle over de logica biedt.

Probleem

Zonder exhaustiveness checking (controle op uitputtende afweging van alle varianten) kan een deel van de kracht van patroonmatching foutief worden geïmplementeerd. Bovendien kan het ontbreken van inzicht in de volgorde van takken en guard-expressies leiden tot fouten in de logica of prestaties.

Oplossing

In Rust controleert de compiler of alle varianten van een enum (of eenvoudigere patroonstructuren) zijn behandeld, of dat er een tak _ is. De tak kan verder worden beperkt met een guard-expressie (if na het patroon), en alleen wanneer de voorwaarde wordt vervuld "gaat deze af". De resterende varianten worden niet gevangen. De volgorde van de takken is belangrijk: ze worden van boven naar beneden gecontroleerd.

Voorbeeld code:

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",
    }
}

Kernkenmerken:

Veiligheid door middel van exhaustiveness checking: de compiler zal geen gevallen negeren (of verplicht je om '_` in te voeren).
Mogelijkheid om een guard te gebruiken voor het uitbreiden van verwerkingsvoorwaarden.
Takken worden van boven naar beneden gecontroleerd, de eerste aansluitende patroon+guard wordt uitgevoerd.

Vragen met een addertje onder het gras.

Wordt de tak met guard geactiveerd als het patroon overeenkomt, maar de voorwaarde niet wordt vervuld?

Nee, in dat geval gaat de controle naar de volgende geschikte tak. Patroon + guard is een atomair "filter"; alleen wanneer beiden overeenkomen, wordt de inhoud van de tak uitgevoerd.

Beïnvloedt de volgorde van takken in match de prestaties?

Ja. Vooral bij een overvloed aan vergelijkbare patronen met guard: de compiler controleert de takken van boven naar beneden, wat de snelheid van de runtime-controle beïnvloedt - vaak voorkomende waarden moeten eerder worden verwerkt.

Kun je exhaustiveness checking negeren door alleen de tak _ in te voegen?

Technisch gezien, ja - dat is toegestaan, maar het verlies van betrouwbaarheid: als het type nieuwe elementen uitsluit (of toevoegt), zal de compiler je niet waarschuwen voor een niet-overwogen geval. Het is beter om altijd belangrijke gevallen expliciet te behandelen en "_" alleen in uiterste gevallen te gebruiken.

Typische fouten en anti-patronen

Het gebruik van guard zonder te beseffen dat het patroon zogenaamd overeenkomt, maar de voorwaarde niet slaagt: niet in aanmerking genomen gevallen.
Het negeren van de volgorde van takken bij dubbelzinnige patronen, onjuiste logica.
Je moet altijd de enum uitputtend analyseren, zonder alles in "_" te stoppen.

Voorbeeld uit het leven

Negatieve case

Match-code voor enum met guard-expressies, waarbij het patroon met guard als laatste komt, maar de meeste waarden rechtstreeks door de vroege tak _ gaan, en nooit de juiste verwerking bereiken.

Voordelen:

Snelle implementatie van een "stopper" in de vorm van _.

Nadelen:

Logica werkt niet, benodigde waarden worden niet gevangen, en de code is moeilijk te testen.

Positieve case

Eerst worden de meest voorkomende en belangrijke varianten opgesomd (met guard), en vervolgens worden de overige uitputtend behandeld - zonder overbodige code in "_".