Pattern bindings of structure variant fields

[mathstuf]

Currently, the following is a syntax error:

enum MyEnum {
    StructVariant {
        a: String,
        b: u64,
    },
}

fn matcher(e: MyEnum) {
    match e {
        MyEnum::StructVariant v@{ .. } => {
            // do something with `v.a` and `v.b`.
        },
    }
}

error: expected one of `::`, `=>`, `if`, or `|`, found `v`                                                                                                                                                                                                                                                                    
  --> src/lib.rs:10:31
   |
10 |         MyEnum::StructVariant v@{ .. } => {
   |                              -^ unexpected token
   |                              |
   |                              expected one of `::`, `=>`, `if`, or `|` here

(Side note, why are { and ( not listed in the expected list?)

When a struct variant has many fields, many of which get used in some match arm, the arm tends to get unwieldy very quickly without resorting to trs vrbl nms.

I also want to avoid making it a 1-tuple variant over another struct because that means giving a name to the structure, exporting it, and documenting it ( andsince its only purpose is to give the variant something capture-able, the struct docstring will basically be either a duplicate or "see this variant").

Open questions (with some gut-level answers of my own):

• What is the type of v above? IMO, it should be unnameable (like a closure), but still potentially implement default traits such as Clone, Copy, Sync, and Send (though another thought makes me think: who can receive this unnamed type other than by a trait object)? This means it probably cannot implement Any as well.
• Can it be returned out of the match or if let? I think so. It's still an unnameable type, so it cannot be returned other than through impl Trait or Box<Trait>.
• Is this a syntax ambiguity? I'm not seeing an obvious one at least.
• Is it applicable to tuple variants as well?

Thoughts?

[SimonSapin]

What is the type of v above?

This is the core of this issue. There is no such type in the language today. A previous RFC about adding them was postponed: #1450

The way forward is probably to read though that discussion, amend the RFC as appropriate, and re-submit it. However since the impl period just started the time to do it is probably after December.

[burdges]

If structural records #1999 (comment) came back eventually then they could provide the type of v.

[mathstuf]

Is there any problem with making them unnameable types though (IIRC, it'd be a new "Voldemort type")? There seem to be lots of issues with making variants types in and of themselves (conversion, coercion, trait implementations, etc.). IMO, if a variant is useful on its own and is getting passed around everywhere, it's probably worthwhile to have an explicit name for it. I can see the benefits of having the ergonomics of just being able to do variant.field if you've already matched the variant elsewhere. That sounds to me like the structural flattening RFC (…though maybe one doesn't exist? a simple search comes up empty).

Differences from that RFC are that I see more value on syntax like Enum::Variant x@{} or Enum::Variant x@() since I don't actually care about the type which may cause confusion if that RFC does get implemented. Though my proposed syntax is unambiguous about the type (even if unnameable).

With it being a Voldemort type, what would errors messages look like? Just mention it by the variant name? Also, if two struct variants have the same internal structure, can they be matched together or are they distinct types (I'd go with the latter personally, but Rust's type system would probably also be able to catch problems if they do get implicitly unified)?