Destructuring enums¶
Level: 101 → 201 · for newcomers
One line: Each variant has a shape, and the pattern for it is that shape with names in the holes — which is why match on an enum is the one place the compiler can tell you that you forgot a case.
Stub — an outline, not a lesson. There is no runnable example behind this page yet, so nothing on it has been through the check that backs every other claim in this library. The bullets below are the questions the finished page has to answer.
What it has to cover¶
- One pattern per variant shape: unit (
Stop), tuple (Move(x, y)), struct-like (Resize { w, h }) - Exhaustiveness, and
E0004printing the variant you missed — the property that makes an enum plus amatcha design tool rather than a switch statement - Why
_is a liability here, and the alternative when you genuinely need one:#[non_exhaustive], or matching the variants you handle and letting the compiler come find you - Nesting:
Some(Ok(n)), and how far to take it before a nestedmatchreads better - The same ownership rule as structs — the bound fields move unless you match a reference
- Where
OptionandResultfit: they are ordinary enums, so everything here is whatif let Some(n)was doing all along
The trap it exists for¶
A lowercase name in an arm is not a constant being compared against — it is a new binding, and it matches everything, so the arms below it are dead. The compiler warns about the unreachable arm but not about the mistake, and the whole story is a typo becomes a binding.
See also¶
- What an enum is · Variants that carry data — the type this page takes apart
- A typo becomes a binding — the trap above, in full, with the two lints that catch it
SomeandNone— the enum you have been destructuring since page one- Six kinds of zero — exhaustiveness used as a domain model
matchexpressions — the keyword and its arm-order rules- Comprehensive Rust: Destructuring Enums ↗
Po polsku¶
Destrukturyzacja wyliczenia to zapisanie wzorca (pattern) w kształcie samego wariantu — Stop, Move(x, y), Resize { w, h } — i wstawienie nazw w dziury. Nazwy po lewej nie odnoszą się do niczego, co już istnieje: to nowe wiązania, tworzone w chwili dopasowania.
Najcenniejsza jest tu jednak nie wygoda, tylko kompletność dopasowania (exhaustiveness): kompilator zna wszystkie warianty wyliczenia, więc potrafi wskazać ten, który pominąłeś, i robi to jako E0004, wymieniając brakujący wariant z nazwy. To właśnie zamienia parę „wyliczenie + match" w narzędzie projektowe, a nie w odpowiednik switch. Dlatego _ na dole jest tu obciążeniem, a nie udogodnieniem: raz dopisany, na zawsze uciszy pytanie „a co z wariantem, który dojdzie za rok?".
Pułapka, przez którą przechodzi każdy: nazwa pisana małą literą w ramieniu nie jest porównaniem ze stałą, tylko nowym wiązaniem — a takie wiązanie pasuje do wszystkiego, więc ramiona pod nim są martwe. Kompilator ostrzeże o nieosiągalnym ramieniu, ale nie o przyczynie, bo z jego punktu widzenia napisałeś dokładnie to, co chciałeś.
Szukaj po polsku: dopasowanie wzorców · destrukturyzacja wyliczeń · kompletność dopasowania · rust match exhaustiveness · E0004