Tracking Issue for RFC 3535: Constants in Patterns

[traviscross]

This is a tracking issue for the RFC 3535: Constants in Patterns (rust-lang/rfcs#3535).

Summary

When a constant appears as a pattern, this is syntactic sugar for writing a pattern that corresponds to the constant's value by hand. This operation is only allowed when (a) the type of the constant implements PartialEq, and (b) the value of the constant being matched on has "structural equality", which means that PartialEq behaves the same way as that desugared pattern.

This RFC does not allow any new code, compared to what already builds on stable today. Its purpose is to explain the rules for constants in patterns in one coherent document, and to justify why we will start rejecting some code that currently works (see the breaking changes).

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC.
  • remove StructuralEq trait #116167
  • make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern #116284
  • update indirect_structural_match and pointer_structural_match lints to match RFC and to show up for dependencies #120423
  • make non-PartialEq-typed consts as patterns a hard error #120805
  • Turn remaining non-structural-const-in-pattern lints into hard errors #124661
• Adjust documentation (see instructions on rustc-dev-guide).
  • update patterns.md for const pattern RFC reference#1456

Status of the relevant lints

• nontrivial_structural_match: removed in update indirect_structural_match and pointer_structural_match lints to match RFC and to show up for dependencies #120423
• const_patterns_without_partial_eq: turned into hard error in make non-PartialEq-typed consts as patterns a hard error #120805
• illegal_floating_point_literal_pattern: partially hard error, rest removed in make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern #116284
• indirect_structural_match: shows up in dependencies starting with Rust 1.78; will be made into hard error by Turn remaining non-structural-const-in-pattern lints into hard errors #124661
• pointer_structural_match: shows up in dependencies starting with Rust 1.78; will be made into hard error by Turn remaining non-structural-const-in-pattern lints into hard errors #124661

Unresolved questions

• When a constant is used as a pattern in a const fn, what exactly should we require? Also see consts in patterns in const contexts with feature effects causes warning (soon: error) about not implementing PartialEq #119398.

Related issues

• Tracking issue for illegal_floating_point_literal_pattern compatibility lint #41620
• Tracking issue for indirect_structural_match compatibility lint #62411
• Tracking issue for const_patterns_without_partial_eq lint #116122
• function pointers as match patterns have optimization-dependent behavior #70861
• Restrict use of constants in patterns (RFC 1445) #31434

[RustyYato]

(see the breaking changes below)

Is there supposed to be a section about breaking changes here? Or perhaps that should link to: https://github.com/rust-lang/rfcs/blob/master/text/3535-constants-in-patterns.md#breaking-changes?