Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e Foo(Bar(x) | Baz(x))" #54883

Closed
6 of 8 tasks
Centril opened this issue Oct 7, 2018 · 66 comments · Fixed by #79278
Closed
6 of 8 tasks

Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e Foo(Bar(x) | Baz(x))" #54883

Centril opened this issue Oct 7, 2018 · 66 comments · Fixed by #79278
Assignees
Labels
A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns A-patterns Relating to patterns and pattern matching B-RFC-approved Approved by a merged RFC but not yet implemented. B-RFC-implemented Approved by a merged RFC and implemented. B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-or_patterns `#![feature(or_patterns)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Oct 7, 2018

This is a tracking issue for the RFC "Or patterns, i.e Foo(Bar(x) | Baz(x))" (rust-lang/rfcs#2535).

This issue also tracks the changes in rust-lang/rfcs#2175 and rust-lang/rfcs#2530 since RFC 2535 subsume those.

Status:

Steps:

Unresolved questions:

  • Should we allow top_pat or pat<allow_top_alt> in inferrable_param such that closures permit |Ok(x) | Err(x)| without first wrapping in parenthesis?

    We defer this decision to stabilization as it may depend on experimentation. Our current inclination is to keep the RFC as-is because the ambiguity is not just for the compiler; for humans, it is likely also ambiguous and thus harder to read.

    This also applies to functions which, although do not look as ambiguous, benefit from better consistency with closures. With respect to function arguments there's also the issue that not disambiguating with parenthesis makes it less clear whether the type ascription applies to the or-pattern as a whole or just the last alternative.

  • Should the pat macro fragment specifier match top_pat in different
    Rust editions or should it match pat<no_top_alt> as currently specified? We defer such decisions to stabilization because it depends on the outcome of crater runs to see what the extent of the breakage would be.

The benefit of avoiding pat<no_top_alt> in as many places as possible would both be grammatical consistency and fewer surprises for uses. The drawbacks would be possible ambiguity or backtracking for closures and breakage for macros.

Implementation history:

@Centril Centril added B-RFC-approved Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Oct 7, 2018
@Centril

This comment has been minimized.

@CAD97

This comment has been minimized.

@Centril

This comment has been minimized.

@CAD97

This comment has been minimized.

@varkor varkor self-assigned this Oct 18, 2018
@varkor

This comment has been minimized.

@alexreg

This comment has been minimized.

@varkor

This comment has been minimized.

@alexreg

This comment has been minimized.

@dlrobertson
Copy link
Contributor

dlrobertson commented Jan 27, 2019

@alexreg thanks for the ping. Haven't really thought about it too much. I've mostly been experimenting with the code, but at this point I am not keen on changing more than the pattern matching code for the following reasons:

  • I don't see much of a benefit in allowing |Ok(x) | Err(x)|
  • | feels very ambiguous here. When we hit a | when parsing a closure, is it a or-pattern
    or the end of the closure argument patterns? We would have to parse past the end to find out.

That being said, I'm still new, so I might be missing something.

@Centril
Copy link
Contributor Author

Centril commented Jan 27, 2019

@dlrobertson Thanks for working on this. The more important part to test with crater is whether top_pat can be used for pat macro fragments or if it has regressions so it would be good to start with top_pat and maybe switch to pat<no_top_alt> based on the data.

I think it's also worth considering fn foo(Ok(x) | Err(x): Result<A, B>) { .. } without parens since that doesn't look ambiguous like with closures (the part about type ascription is also irrelevant since both p and q must have the same type in p | q so it shouldn't matter what the ascription applies to). But we can leave that for later.

@alexreg

This comment has been minimized.

@dlrobertson

This comment has been minimized.

@dlrobertson

This comment has been minimized.

bors added a commit that referenced this issue Aug 18, 2019
Initial implementation of or-patterns

An incomplete implementation of or-patterns (e.g. `Some(0 | 1)` as a pattern). This patch set aims to implement initial parsing of `or-patterns`.

Related to: #54883

CC @alexreg @varkor
r? @Centril
@Centril Centril added the F-or_patterns `#![feature(or_patterns)]` label Aug 18, 2019
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 20, 2020
or_patterns: implement :pat edition-specific behavior

cc rust-lang#54883 `@joshtriplett`

This PR implements the edition-specific behavior of `:pat` wrt or-patterns, as determined by the crater runs and T-lang consensus in rust-lang#54883 (comment).

I believe this can unblock stabilization of or_patterns.

r? `@petrochenkov`
@mark-i-m
Copy link
Member

mark-i-m commented Dec 20, 2020

The 2015/18 edition behavior has merged in #80100.

Does it make sense to start an FCP for stabilization?

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Dec 31, 2020
Implement edition-based macro :pat feature

This PR does two things:
1. Fixes the perf regression from rust-lang#80100 (comment)
2. Implements `:pat2018` and `:pat2021` matchers, as described by `@joshtriplett`  in rust-lang#54883 (comment) behind the feature gate `edition_macro_pat`.

r? `@petrochenkov`

cc `@Mark-Simulacrum`
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 31, 2020
Implement edition-based macro :pat feature

This PR does two things:
1. Fixes the perf regression from rust-lang#80100 (comment)
2. Implements `:pat2018` and `:pat2021` matchers, as described by `@joshtriplett`  in rust-lang#54883 (comment) behind the feature gate `edition_macro_pat`.

r? `@petrochenkov`

cc `@Mark-Simulacrum`
@mark-i-m
Copy link
Member

mark-i-m commented Jan 1, 2021

Happy New Year, all! 🎉

With the merging of #80459, the pat2018/pat2021 behavior that @joshtriplett described from the lang-team consensus is implemented behind feature gate edition_macro_pats.

If everything looks reasonable, I think we can stabilize or_patterns in rust 1.51. #79278 is up to date and ready for an FCP.

@joshtriplett
Copy link
Member

joshtriplett commented Jan 26, 2021

@petrochenkov Filed #81415 to check for lang-team consensus.

@joshtriplett
Copy link
Member

joshtriplett commented Feb 2, 2021

@petrochenkov It looks like we have consensus to make that change, so please feel free to simplify that bit of the grammar by allowing leading | everywhere we allow or patterns.

@mark-i-m
Copy link
Member

mark-i-m commented Feb 3, 2021

I think we can make this change independently of stabilizing or-patterns because macros in 2015/18 can't see the change yet anyway, correct?

@CAD97
Copy link
Contributor

CAD97 commented Mar 22, 2021

The head comment should probably be updated to reflect the stableization of the feature.

flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 25, 2021
…matsakis

Stabilize or_patterns (RFC 2535, 2530, 2175)

closes rust-lang#54883

This PR stabilizes the or_patterns feature in Rust 1.53.

This is blocked on the following (in order):
- [x] The crater run in rust-lang#78935 (comment)
- [x] The resolution of the unresolved questions and a second crater run (rust-lang#78935 (comment))
    - It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (rust-lang#80100).
- [ ] An FCP on stabilization

EDIT: Stabilization report is in rust-lang#79278 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns A-patterns Relating to patterns and pattern matching B-RFC-approved Approved by a merged RFC but not yet implemented. B-RFC-implemented Approved by a merged RFC and implemented. B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-or_patterns `#![feature(or_patterns)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.