Strum

Strum is a Rust library that eliminates the boilerplate of converting enums to and from strings and other representations. Rather than hand-writing match statements for Display, FromStr, or iteration over an enum’s variants, Strum provides derive macros — EnumString, Display, EnumIter, EnumCount, EnumProperty, EnumDiscriminants, VariantNames, and more — that generate this code automatically at compile time.

The project is split into two crates that are typically used together: strum holds the traits consumed by generated code, and strum_macros (importable directly through strum’s derive feature) provides the actual procedural macros. This split keeps the runtime dependency lightweight while all the code-generation logic lives in the macro crate, which is only needed at compile time.

What You Get

• EnumString/Display derives for parsing enums from strings and formatting them back to strings
• EnumIter to generate an iterator over all variants of an enum, and EnumCount/VariantArray/VariantNames for variant metadata as constants
• FromRepr to convert integer discriminants back into enum variants
• EnumProperty/EnumMessage to attach custom key-value properties or human-readable messages to individual variants via attributes
• EnumDiscriminants to generate a companion enum containing only the variant names/discriminants, useful for matching without carrying variant data

Common Use Cases

• Parsing configuration values or CLI arguments into strongly-typed enums via EnumString
• Rendering enum variants as human-readable strings in logs, error messages, or UI labels via Display
• Iterating over all possible variants of an enum for validation, test generation, or building selection UIs via EnumIter
• Attaching metadata like display names or descriptions to enum variants for use in APIs or documentation via EnumProperty/EnumMessage

Under The Hood

Architecture The project is a Cargo workspace split into strum (the small runtime crate exposing the traits that generated code implements, in strum/src/lib.rs) and strum_macros (the procedural macro crate that does all the actual code generation, parsing enum definitions and their attributes with syn to emit trait implementations). This separation means consumers who only need the traits (e.g. for trait objects across a workspace) can depend on strum without pulling in syn/quote at all, while the derive feature flag re-exports the macros from strum_macros for the common case of using both together. A STRUM_DEBUG environment variable lets users dump the generated code for debugging macro output, and strum_tests/strum_nostd_tests provide integration coverage across std and no_std configurations.

Tech Stack Pure Rust, edition 2021, with strum_macros depending on the standard proc-macro toolchain (syn, quote, proc-macro2) while the strum crate itself has zero required dependencies beyond an optional phf for perfect-hash-based string matching and an optional path dependency on strum_macros gated behind the derive feature. The crate explicitly targets a 2-year-plus rustc compatibility window (currently rustc >= 1.71.1).

Code Quality Testing is split across dedicated strum_tests (std) and strum_nostd_tests (no_std) crates that exercise every derive macro’s generated code as integration tests rather than only unit tests within the macro crate — an appropriate structure for a proc-macro library, since the real correctness surface is the code it generates, not the macro implementation in isolation. CI runs via GitHub Actions (ci.yml), and the project has a stated 2-year rustc support policy that signals a deliberate, conservative maintenance stance.

API Design The API surface for consumers is almost entirely declarative: adding #[derive(EnumString, Display, ...)] above an enum, optionally with per-variant #[strum(...)] attributes for customization (renaming, serialization strings, properties). This keeps boilerplate to a single derive line per desired behavior, though understanding the full space of #[strum(...)] attribute options requires consulting the docs, since attribute-driven APIs are inherently less discoverable via autocomplete than method-based ones.