Tracking issue for ..X, and ..=X (#![feature(half_open_range_patterns)])

[Centril]

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.

[Centril]

The implementation in #67258 landed on 2020-01-11. The PR was written by @Centril and reviewed by @oli-obk.

• Follow up with implementing Introduce X.., ..X, and ..=X range patterns #67258 (comment).

[Centril]

In #68120, which landed on 2020-01-11, the ...X syntax was prohibited, addressing #67258 (comment). Some diagnostics were also improved and tests were hardened. The PR was written by @Centril and reviewed by @oli-obk.

Everything should be well tested and implemented now. Once we have a new bootstrap compiler, we can start using it internally in the compiler, and eventually consider stabilization together with X..Y patterns.

[jyn514]

Is this waiting on anything to be stabilized? I would have liked to use it in a complicated match.

[jplatte]

Last comments from #68859 (Dogfood half_open_range_patterns):

@Mark-Simulacrum wrote

To be honest, I find these much harder to read. Maybe I'm just not used to it yet, but it's entirely non obvious to me that we're omitting specifically a zero. It also seems largely useless as I can't really see a case where this is better (i.e. where the zero was in the way before).

I'm not sure what to do with this information. This feature was implemented without an RFC, as far as I can tell.

I think the fact that these ranges don't have iterator impls is part of it...

@Centril wrote

I'll close this for now then and you can consider what to do with the information. Personally, I think the feature adds a degree of consistency to patterns & expressions (and X.. is generally useful but ..X less so).

So it seems this might be waiting on dogfooding still? Can't find any uses of this feature in the compiler.

[jyn514]

In that case, could we stabilize X.. without stabilizing the others? That seems both more clear and more useful than the other alternatives, since the current stable version is an if guard, while the others can be written with 0..

[Mark-Simulacrum]

I'm going to go ahead and nominate for lang to look at in triage. I am less uncertain about 0.. (compared to ..5), I think because the latter feels less obvious what it starts at. 0.. may end at i32::MAX or u32::MAX, for example, but both of those are more-or-less the same from a "what it is" perspective (unlike "0" or i32::MIN, which is quite different).

Could you point at an example of where you wanted to use this more precisely, and maybe a diff between the two? Personally I feel like explicitly adding u/iN::MAX/MIN is probably not too much more writing in practice...

[nikomatsakis]

I guess I had assumed ..5 would be going from the "minimum value", but you're correct that I could see people being quite surprised that it was not starting from 0 (i.e., they may have thought of the value as unsigned and not realized it was signed, for example).

[jyn514]

This was the exact use case:

    // on stable
    match delta {
        (days, ..) if days > 5 => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
        (days @ 2..=5, ..) => format!("{} days ago", days),
        (1, ..) => "one day ago".to_string(),

        (0, hours, ..) if hours > 1 => format!("{} hours ago", hours),
        (0, 1, ..) => "an hour ago".to_string(),

        (0, 0, minutes, _) if minutes > 1 => format!("{} minutes ago", minutes),
        (0, 0, 1, _) => "one minute ago".to_string(),

        (0, 0, 0, seconds) if seconds > 0 => format!("{} seconds ago", seconds),
        _ => "just now".to_string(),
    };
    // on nightly
    match delta {
        (6.., ..) => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
        (days @ 2..=5, ..) => format!("{} days ago", days),
        (1, ..) => "one day ago".to_string(),

        (0, hours @ 2.., ..) => format!("{} hours ago", hours),
        (0, 1, ..) => "an hour ago".to_string(),

        (0, 0, minutes @ 2.., _) => format!("{} minutes ago", minutes),
        (0, 0, 1, _) => "one minute ago".to_string(),

        (0, 0, 0, seconds @ 1..) => format!("{} seconds ago", seconds),
        _ => "just now".to_string(),
    }

Personally I feel like explicitly adding u/iN::MAX/MIN is probably not too much more writing in practice...

I guess the main difference is that requires you to know what type delta is ... with X.. you'd only have to know {integer}. I'd prefer not to have to think about whether seconds are i32 or i64 or something else. The stable version I posted uses if-guards instead which have the downside you no longer get exhaustiveness checking.

they may have thought of the value as unsigned and not realized it was signed, for example

right - I realized when trying to make this an exhaustive match that this was actually a signed integer when I thought it was unsigned. Actually I think we don't handle the negative case in docs.rs ...

[joshtriplett]

I do think we have clearer semantics to allow stabilizing X.., but I also think that would lead people to expect ..X to work, and to find it surprising if that doesn't work.

I also think we already have some unusual semantics for half-open ranges. For instance, ..X (RangeTo) is not an iterator, so you can't write for x in ..5.

We've already defined the semantics of RangeTo and similar, and they do start from the minimum value for the type, so (..5).contains(&-3i8) is true. I agree that that's potentially confusing, but I think that confusion hasn't manifested in practice because RangeTo and similar doesn't work in iteration or patterns, so the main place I'd expect to see it would be in things like Vec and slices, where it's specifically a range over usize.

On the other hand, for loops over a range do end up using different integer types sometimes. As long as you're not using the iteration variable in an indexing operation, the type constraint may not be usize, so if you're working with an API that expects (say) an i32, type inference might turn your loop index into an i32, and you might be really surprised to find your loop starting from -2147483648 instead of 0.

For that reason, I'm hesitant to support pattern matching using RangeTo and RangeToInclusive.

I don't have any fundamental objections to stabilizing pattern matching using RangeFrom, though. My only concern is if it leads people to find it surprising that we don't support other half-open patterns. But we could document why we don't, and summarize in the error we'd give for a ..X or ..=X pattern.

[joshtriplett]

@jyn514 For that specific match, if you switched to unsigned types, you could write this, which I think would be clearer:

    match delta {
        (0, 0, 0, 0) => "just now".to_string(),
        (0, 0, 0, seconds) => format!("{} seconds ago", seconds),
        (0, 0, 1, ..) => "one minute ago".to_string(),
        (0, 0, minutes, ..) => format!("{} minutes ago", minutes),
        (0, 1, ..) => "an hour ago".to_string(),
        (0, hours, ..) => format!("{} hours ago", hours),
        (1, ..) => "one day ago".to_string(),
        (days @ 2..=5, ..) => format!("{} days ago", days),
        _ => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
    }

And that should work on stable. It wouldn't work for signed values, but I don't think the original handles the negative case anyway.

[tormol]

I wanted to use this today to validate a libc struct while assuming as little as possible about the field types:

match timeout {
    timeval { tv_sec: sec @ 0.., tv_usec: usec @ 0..1_000_000, .. } => Ok((sec, usec)),
    timeval { tv_sec: ..0, .. } => Err("is negative"),
    timeval { tv_usec: 1_000_000.., .. } | timeval { tv_usec: ..0, .. } => Err("has invalid microsecond part"),
}

Half-open ranges here have the benefit of not needing to know the signedness or size. (..0 either covers all negative numbers or is an empty range, and 0.. covers all natural numbers without having to specify the type to get the max value)

[nikomatsakis]

@rfcbot resolve rust-reference

[nikomatsakis]

@rfcbot concern rust-reference

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

oops, looks like that is still a problem?

[Havvy]

Does this stabilize using range patterns in slice pattern subpatterns at toplevel? Currently, a slice pattern of [1, 2.., 3] doesn't work and it says to require this feature. Furthermore, there is no open tracking issue for it. If not, we should open an issue for it. And if so, does everybody checking their box understand that?

---

Relatedly, I'm currently working on the documentation PR for this.

[AaronKutch]

edit: whoops wrong specific issue, and I realized x.. as an iterator is older than it being a pattern

[jhpratt]

@AaronKutch How is that in any way related to this feature?

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[ehuss]

Just to elaborate on Havvy's comment about slice patterns since I was a little confused:

The half_open_range_patterns feature gate originally covered various different forms. Parts have been stabilized over time. It currently gates the use of ..=X half-open range pattern, and separately the use of X.. in slice patterns (only).

I believe the slice pattern restriction stems from this comment to future-proof a hypothetical syntax to make it easier to match on slices (and a summary in this comment). This is exhibited in the slice_pattern_syntax_problem0.rs and slice_pattern_syntax_problem1.rs tests.

The question is which option should be taken for the slice restriction:

• Add a new feature gate and tracking issue?
• Just permanently disallow it?
• Just stabilize it and give up on the idea of extending the syntax in the future (or consider an edition change)?
• Something else?

[jplatte]

This was stabilized in #102275, I think this issue can be closed.

[ehuss]

This issue is open because half_open_range_patterns_in_slices is still unstable. I have updated the top comment. It probably should have gotten its own tracking issue, though.