Tracking issue for RFC 2591: precise pattern matching on pointer size types #56354

Activity

1. Centril

   added

   T-langRelevant to the language teamRelevant to the language team

   C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC

   on Nov 30, 2018
2. jonas-schievink

   added

   B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.

   on Oct 23, 2019
3. SergioBenitez commented on Oct 23, 2019

   

   SergioBenitez

   on Oct 23, 2019

   Contributor

   More actions

   Is there anything preventing the stabilization of this feature?

   👍React with 👍1Reacted by Stanislav Tkach
4. varkor commented on Oct 23, 2019

   

   varkor

   on Oct 23, 2019

   ContributorAuthor

   More actions

   I think we'd need an RFC, or at the very least, a detailed motivation. The problem is that pointer size types have different ranges depending on the target platform, and so there was concern that this could cause confusion. See rust-lang/rfcs#2591 (comment) and rust-lang/rfcs#2591 (comment) for details.
5. workingjubilee

   added

   A-exhaustiveness-checkingRelating to exhaustiveness / usefulness checking of patternsRelating to exhaustiveness / usefulness checking of patterns

   A-patternsRelating to patterns and pattern matchingRelating to patterns and pattern matching

   on Apr 9, 2021
6. workingjubilee commented on Apr 9, 2021

   

   workingjubilee

   on Apr 9, 2021

   Member

   More actions

   I believe that if half_open_range_patterns receive partial or total stabilization as discussed in #67264, it might allow for patterns that more usefully handle various cases here. This could be particularly useful when you want to match on e.g. the length of an array, Vec, or anything else that would produce an ExactSizeIterator (an example I have seen is matching against the count of arguments to a CLI).

   👍React with 👍1Reacted by scottmcm
7. joshtriplett

   added

   S-tracking-design-concernsStatus: There are blocking design concerns.Status: There are blocking design concerns.

   on Jun 8, 2022
8. roblabla commented on Oct 4, 2022

   

   roblabla

   on Oct 4, 2022

   Contributor

   More actions

   I am so confused by this. I currently have code to the effect of

   match 0usize {
       0..=9 => { /* some code that only runs on small numbers */ },
       10.. => { /* some code that handles everything else */ },
   }

   This triggers this hard error. I'm... not sure I understand the rationale behind this.

   I can understand denying precise pointer matching when hardcoding numbers, but it seems to me like half-open ranges should obviously be accepted here - there is no room for any confusion or portability issues. And this isn't even a lint, so we can't #[allow] it away...

   Could half-open ranges on usize be allowed to exhaustively match?
9. workingjubilee commented on Mar 5, 2023

   

   workingjubilee

   on Mar 5, 2023

   Last edited by workingjubilee

   Member

   More actions

   I will write up a formal proposal for this, as I attempted to move half-open range patterns along a bit so that we could specifically have this.
10. workingjubilee

    self-assigned this

    on Mar 5, 2023
11. workingjubilee

    removed their assignment

    on Oct 15, 2023
12. Nadrieril commented on Dec 1, 2023

    

    Nadrieril

    on Dec 1, 2023

    Member

    More actions

    @roblabla's example above now works as expected. Given that half-open ranges can now be used to match exhaustively on usize/isize, is this feature still useful?
13. Nadrieril commented on Dec 4, 2023

    

    Nadrieril

    on Dec 4, 2023

    Member

    More actions

    In #118598 I propose to deprecate this feature gate in favor of half-open range patterns
14. matthiaskrgr

    added a commit that references this issue on Dec 5, 2023

    Rollup merge of rust-lang#118598 - Nadrieril:remove_precise_pointer_s…

    ...

    81b6263
15. bors

    closed this as completedin 81b6263on Dec 5, 2023
16. rust-timer

    added a commit that references this issue on Dec 5, 2023

    Unrolled build for rust-lang#118598

    ...

    0a6f57d