Restrict use of constants in patterns (RFC 1445)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1445.

Implementation steps:

• disable pattern expansion for user-defined types unless tagged with #[structural_match]
• disable pattern matching for floating point constants
• have #[derive(Eq)] add #[structural_match] attribute
• exhaustiveness, dead-code integration
• indirect_structural_match lint misfiring on enum variant unused in const item #62614, a bug that led us to rollback on Tracking issue for indirect_structural_match compatibility lint #62411 .
• "Structural match" annotations should be moved from struct/enum items to impl items #63438: move from #[structural_match] attribute to something with impl items (e.g. a Structural trait)

[durka]

Why #[derive(Eq)] and not #[derive(PartialEq)]? I see this was brought up in the RFC thread but I didn't really see any reasons given.

[nikomatsakis]

See the PR #32199

[nikomatsakis]

@durka

Why #[derive(Eq)] and not #[derive(PartialEq)]? I see this was brought up in the RFC thread but I didn't really see any reasons given.

The primary reason is that types which only implement PartialEq are not really compatible with a "structural" interpretation. For example, imagine you have a match that tests against the floating point value NaN -- should this match, or not? Consider that NaN != NaN (and hence floating point types are not Eq). Currently, we sidestep this by disallowing a constant of NaN, but we won't be able to do that in the future. And there are other weird examples. Consider 0 vs -0 -- these are distinct values (different bitpatterns) and yet they compare equal. So should match foo { 0 => ... } trigger if foo is -0? Today, it does, but that is a special case for floating point values, and we don't afford user-defined types the same courtesy (that is, we use a strict structural match for user-defined types).

If we wind up adopting a "semantic" interpretation, then we could consider loosening to PartialEq.

[brson]

Nominating for status update.