Design meeting: Decide about the future for consts in patterns

[RalfJung]

Summary

We allow using (some) constants in patterns. However, we cannot allow all of them: some just don't have a way of being compared, such as unions; others get rejected for being "not structural-match", as defined in RFC 1445. The structural-match check had some holes so some constants that we do accept get linted as "this will be an error in the future". These lints were introduced a long time ago and have been warn-by-default since Rust 1.48, close to 3 years ago. Since then the pattern matching implementation in the compiler changed a lot and our ideas of what we do and don't want to do with pattern matching also changed. We also realized there are some gaps in what the RFC discusses, such as raw pointers.

It's time to figure out where we want to go with this.

Background reading

Design meeting document: https://hackmd.io/@CV5q1SRASEuY8WfOgd_3iQ/rk-b3D6Ja

Some relevant related issues:

• Clarify "structural equality" rules rust#74446
• Tracking issue for illegal_floating_point_literal_pattern compatibility lint rust#41620
• Tracking issue for indirect_structural_match compatibility lint rust#62411
• function pointers as match patterns have optimization-dependent behavior rust#70861
• Handle generic associated constants in const qualification for structural match  rust#73448
• StructuralEq trait docs are outdated rust#115881
• Tracking issue for const_patterns_without_partial_eq lint rust#116122

About this issue

This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.