Skip to content

Stabilization proposal for #![feature(if_while_or_patterns)] #56212

Closed

Description

@Centril

Stabilization proposal

I propose that we stabilize #![feature(if_while_or_patterns)].

Originally proposed in RFC rust-lang/rfcs#2175, then amended by rust-lang/rfcs#2530, implemented (partially, see below) in #48490 by @petrochenkov, and available in nightly since ~25th February, #![feature(if_while_or_patterns)] permits users to write multiple "or patterns" A(x) | B in if let, while let, for expressions and let statements.

See the motivation for an extended discussion; The primary reasons why this is useful are:

  • It permits more expressive and ergonomic control flow.

  • It is consistent with the behaviour of match expressions.

Version target

The next version is 1.32 which goes into beta the 7th of December; It is quite possible that this will slip into 1.33 however depending on how long the review process takes.

What is stabilized

Users are now permitted to write for example:

enum Thing { Alpha, Beta(u8), Gamma }

if let Thing::Alpha | Thing::Gamma = Thing::Gamma {
    ...
}

if let 0 | 1 = 0 { ... } else { ... }

let mut iter = make_thing_iter();
while let | Thing::Beta(_) | Thing::Gamma = iter.next() {
    ...
}

Per rust-lang/rfcs#2530, leading vertical bars (|) are permitted; however, this behaviour cannot be observed on nightly right now. This is a fairly minor thing that will need to be fixed (+ test) in the stabilization PR.

EDIT: A clarification: you can write if let A(x) | B(x) = expr { ... }. In other words, bindings do work.

What is not

Users are not yet permitted to write:

  • if let A(0 | 1) = expr { ... };

    This is the generalization of or-patterns as provided for by RFC: Or patterns, i.e Foo(Bar(x) | Baz(x)) rfcs#2535. @varkor is currently working on an implementation for that generalization.

  • let Ok(x) | Err(x) = expr; or for Ok(x) | Err(x) in iter { ... }.
    This is provided for by the RFC but the implementation was more complex so this will be implemented in the future, possibly by @varkor in the generalization.

    This is a divergence from the RFC since a subset of the RFC is implemented.

Activity

  1. added
    T-langRelevant to the language team
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Nov 25, 2018
  2. Centril commented on Nov 25, 2018

    @Centril
    ContributorAuthor

    @rfcbot merge

    Tracking issue is: #48215

  3. rfcbot commented on Nov 25, 2018

    @rfcbot

    Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

    Concerns:

    Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    See this document for info about what commands tagged team members can give me.

  4. added
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.
    on Nov 25, 2018
  5. joshtriplett commented on Nov 25, 2018

    @joshtriplett
    Member

    @rfcbot concern subset-without-bindings

    I feel like there's little point in stabilizing this without stabilizing bindings (the Ok/Err case). What's the urgency?

  6. Centril commented on Nov 25, 2018

    @Centril
    ContributorAuthor

    @joshtriplett

    There's not an urgency per se; it's just useful to have if let A | B = expr { ... } in stable Rust so that people can start using it; for example, there are places in the standard library where this would make code nicer. Targeting 1.32 is just because it's the closest nearby; if it slips to 1.33 then that's entirely fine, or we can, as @petrochenkov suggested, backport the stabilization PR to beta.

    Wrt. the subset-without bindings, I had the same reaction as you, #48215 (comment); this was then discussed by @petrochenkov (#48215 (comment)), with me being unsure in #48215 (comment), and Niko noting finally in #48215 (comment) that piecemeal stabilization seems fine.

  7. joshtriplett commented on Jan 3, 2019

    @joshtriplett
    Member

    Thanks for the edit clarifying the current status of bindings.

    @rfcbot resolved subset-without-bindings
    @rfcbot reviewed

  8. added
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    on Jan 8, 2019
  9. rfcbot commented on Jan 8, 2019

    @rfcbot

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

  10. removed
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    on Jan 8, 2019
  11. self-assigned this
    on Jan 11, 2019
  12. jonas-schievink commented on Jan 11, 2019

    @jonas-schievink
    Contributor

    Is this perhaps supposed to say while let | instead of while |?

    while | Thing::Beta(_) | Thing::Gamma = iter.next()
  13. Centril commented on Jan 11, 2019

    @Centril
    ContributorAuthor

    @jonas-schievink yes, oops, thanks :) (edit: fixed)

  14. Centril commented on Jan 12, 2019

    @Centril
    ContributorAuthor

    Stabilized (#57532) just now so closing.

  15. added and removed
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    on Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-langRelevant to the language teamdisposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions