Named patterns for handling large enums

Something I've come across a few times while writing Rust is that I sometimes need to copy and paste large chunks of my match statements because several variants of an enum are related in ways that don't hold for other variants of the enum.

There are are several good examples where this would be useful in, for example, the DWARF debuginfo spec. There's something like 20 different large sets of tags that are specified. DW_FORM in particular represents data types, so several subsets of the 'variants' of that make sense to be lumped together- the string-like data types, the 8 byte integers, the pointers, for example. Although the variant-lumping problem could be somewhat solved by making nested enums, that would add majorly to the amount of noise required to perform an exhaustive match. Though, that doesn't address the possible need for a variant to be a member of multiple otherwise disjoint groups.

It would be nice if we could give names to patterns to handle this situation. Here's a condensed example, which really doesn't demonstrate the potential LOC savings that you would get with something like DWARF tags. The real benefit would come from reusing the pattern to prevent code duplication over several functions:

enum Mode {
    Serve(String),
    Capture(u32, String),
    Extract(String),
    Daemon,
    List(u32),
}

use Mode::*;

pattern HasStringArg(String) = Serve(s) | Capture(_, s) | Extract(s);

impl Mode {
    pub fn get_target(&self) -> String {
        match self {
            HasArg(s) => s.clone(),
            Daemon => "daemon".to_string(),
            List => "list".to_string(),
        }
    }
}

That's a rough draft of how this might ultimately look, but it's a feature that would be nice to have to support good strong typing practices.

No implementation files or tests are identified; the issue is a rough design proposal for named patterns in Rust. Start by evaluating the proposed syntax and its interaction with exhaustive matching, bindings, and reusable patterns. Done would require a settled design and clear semantics before implementation can be scoped.