Tracking issue for ..X, and ..=X (#![feature(half_open_range_patterns)]) · Issue #67264 · rust-lang/rust (original) (raw)

X.. was stabilized in #83918
..=X was stabilized in #102275
...X was removed in #68120

..X is tracked in #37854
X.. patterns in slices are currently gated via half_open_range_patterns_in_slices

This is a tracking issue for the feature gate #![feature(half_open_range_patterns)]. This feature provides half-open range patterns X.., ..X, ..=X, and ...X (last one is also deprecated like X...Y is, for spec & implementation simplicity). These correspond to the RangeFrom, RangeTo, RangeToInclusive, and RangeToInclusive expression forms, with the same syntaxes, respectively. The correspondence is both syntactic and semantic (in the sense that e.g. a X.. pattern matching on a scrutinee s holds exactly when (X..).contains(&s) holds). For implementations details, see #67258.

The implementation for the feature was introduced in #67258 and is also strongly related to #![feature(exclusive_range_pattern)] (X..Y) which is also required for X.. and ..X (as the RangeEnd::Exclusive syntax is used).

Steps:

• Once half_open_range_patterns have had some time to bake on nightly, write up an RFC specifying both exclusive_range_pattern and half_open_range and proposing their stabilization.

Unresolved questions:

• Possibly rethink the precedences, Operators in patterns have incorrect priorities #48501. We could ship without fixing this and leaving in the ambiguity errors. EDIT: Lang team considers this an orthogonal issue.
• The primary question to resolve is whether the lack of clarity around ..X for signed types being from -i32::MAX -- is that OK? Too confusing? EDIT: Lang team considers this acceptable, leaving open the possibility of future lints to help catch mistakes.