-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
eRFC: if- and while-let-chains, take 2 #2497
Conversation
I am very for this change. This syntax feels natural and intuitive, and it is something I've pined for. My remarks are:
|
Thank you for the data point and the remarks. I think the primary motivation for also changing That said, if we consider iterating over multiple sources that produce elements in a zip-like fashion (but not strictly
I'm personally undecided on adding |
@aturon has asked me to clarify what exactly is being proposed to be accepted with this RFC. So here goes... The precedent set by closing RFCs #2443, #2441, and #2429 is that we don't accept RFCs reserving syntax without accepting a feature along with it. Therefore, to be consistent with this policy, and for the purposes of making So the idea with this RFC is that we accept the full feature now (the idea of chaining...), but leave finalizing the syntax itself unresolved-ish as we did with #2071 ( After the Rust 2018 has shipped, and when we have time, we can then implement the proposed syntax and experiment with it on nightly. The syntax will still have to be finalized by some other decision, such as with another RFC or on the tracking issue. |
My opinion hasn't changed since #2260 (comment). We should aim for supporting a convenient non-exhaustive pattern-matching expressions in general (
That's just not true, for expressions in If "slow to develop" refers to my promise to write an RFC for pattern-matching expressions |
@petrochenkov Totally understood -- did you see @Centril's clarifying comment? My understanding is that this RFC is meant to commit us to (1) some solution to this problem and (2) carving out a bit of space in the grammar so that the solution could be as discussed in the RFC. FWIW, I also have significant misgivings about solving this problem by essentially extending the special-cased treatment of @Centril I wonder if this should be made formally an "eRFC" to signify more clearly the issues above? |
@aturon |
These operators all have lower precedence than
Which means we also have the following ambiguity to consider: if let Range { start: _, end: false } = true..true && false {
println!("(current behavior)");
} else {
panic!();
} let result = loop {
if let Some(0u32) = break true && false {
panic!();
}
panic!();
};
assert_eq!(result, false); And then const F: fn() -> bool = || true;
if let Range { start: F, end } = F..|| false {
println!("(current behavior)");
assert!(!end());
} else {
panic!();
} let t = &&true;
if let Range { start: true, end } = t..&&false {
println!("(current behavior)");
assert_eq!(**end, false);
} else {
panic!();
} Please also ensure the parser accepts the following: if a || b {} // <-- no parenthesis, it is ok.
if a && b || c && d {}
// interpret as: `(a && b) || (c && d)` and rejects the following before if let Some(a) = b && c || d {}
// interpret as: `((let Some(a) = b) && c) || d` |
@aturon eRFC it is ;) @petrochenkov Yep, it's about making the proposed solution possible and recognizing that some solution (which could be I would personally be fine with experimenting with
I see; my impression was that it was more complicated from the discussions at #2260. This is the "bindings only live until the end of a full expression" rule?
Not at all :) It is referring to my perception of the support for
I thank you for it β€οΈ |
I can't say I'm a huge fan of the specific proposed syntax, but I'm inclined to take this step regardless, so that even if we don't end up going with this particular syntax we can detect potentially ambiguous uses of it. I'm honestly tempted to argue that either grouping should require parentheses. Minor nit: for consistency, can you please always put Also, in the example of how |
@Centril I somehow couldn't find in this RFC if the sudden precedence change of the
The phrasing here is not particularly clear (e.g. what is |
The precedence change is to bind
I agree; it wasn't my finest phrasing. These days I think it's better to think of this in terms of what happens to |
@Centril Thanks for the explanation! |
@H2CO3 Welcome :) |
Argh, I didnβt see that RFC and I wish I didβ¦ Iβm not a huge fan of the proposal, it seems too niche and introduces too much sugar (mixes two very different constructs β |
This is definitely not niche; in particular, this pattern arises frequently in the compiler (similar code like proc macros, clippy, anything that deals with AST-looking trees) and will pay for itself many times over. |
Yes, but
Which is definitely not part of the language (and shouldnβt, as introducing bindings in expressions seems completely out of question). So, yeah, maybe youβre introducing βconceptually simplerβ sugar for very specific cases (again, IΒ truly think itβs niche, and you put on a name on that niche: compilers and ASTs), but youβre also introducing confusion pretty much everywhere else where that βconceptually simplerβ concept would feel applicable (while itβs not). |
I would also like to mention that |
Just yesterday I wanted this feature while changing the MPSC channels in |
In the code you showed, you could have used a guarded match. Thatβs already part of the language and it will do the job for most cases. Having lazy pattern-matching mixed with booleans makes me incomfortable. Iβm not saying Iβm against lazy pattern-matching (itβs actually handy). Iβm just saying that using the |
β¦shtriplett Stabilize `let_chains` in Rust 1.64 # Stabilization proposal This PR proposes the stabilization of `#![feature(let_chains)]` in a future-compatibility way that will allow the **possible** addition of the `EXPR is PAT` syntax. Tracking issue: rust-lang#53667 Version: 1.64 (beta => 2022-08-11, stable => 2022-10-22). ## What is stabilized The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example: ```rust pub enum Color { Blue, Red, Violet, } pub enum Flower { Rose, Tulip, Violet, } pub fn roses_are_red_violets_are_blue_printer( (first_flower, first_flower_color): (Flower, Color), (second_flower, second_flower_color): (Flower, Color), pick_up_lines: &[&str], ) { if let Flower::Rose = first_flower && let Color::Red = first_flower_color && let Flower::Violet = second_flower && let Color::Blue = second_flower_color && let &[first_pick_up_line, ..] = pick_up_lines { println!("Roses are red, violets are blue, {}", first_pick_up_line); } } fn main() { roses_are_red_violets_are_blue_printer( (Flower::Rose, Color::Red), (Flower::Violet, Color::Blue), &["sugar is sweet and so are you"], ); } ``` ## Motivation The main motivation for this feature is improving readability, ergonomics and reducing paper cuts. For more examples, see the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md). ## What isn't stabilized * Let chains in match guards (`if_let_guard`) * Resolution of divergent non-terminal matchers * The `EXPR is PAT` syntax ## History * On 2017-12-24, [RFC: if- and while-let-chains](rust-lang/rfcs#2260) * On 2018-07-12, [eRFC: if- and while-let-chains, take 2](rust-lang/rfcs#2497) * On 2018-08-24, [Tracking issue for eRFC 2497, "if- and while-let-chains, take 2](rust-lang#53667) * On 2019-03-19, [Run branch cleanup after copy prop](rust-lang#59290) * On 2019-03-26, [Generalize diagnostic for x = y where bool is the expected type](rust-lang#59439) * On 2019-04-24, [Introduce hir::ExprKind::Use and employ in for loop desugaring](rust-lang#60225) * On 2019-03-19, [[let_chains, 1/6] Remove hir::ExprKind::If](rust-lang#59288) * On 2019-05-15, [[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains](rust-lang#60861) * On 2019-06-20, [[let_chains, 3/6] And then there was only Loop](rust-lang#61988) * On 2020-11-22, [Reintroduce hir::ExprKind::If](rust-lang#79328) * On 2020-12-24, [Introduce hir::ExprKind::Let - Take 2](rust-lang#80357) * On 2021-02-19, [Lower condition of if expression before it's "then" block](rust-lang#82308) * On 2021-09-01, [Fix drop handling for `if let` expressions](rust-lang#88572) * On 2021-09-04, [Formally implement let chains](rust-lang#88642) * On 2022-01-19, [Add tests to ensure that let_chains works with if_let_guard](rust-lang#93086) * On 2022-01-18, [Introduce `enhanced_binary_op` feature](rust-lang#93049) * On 2022-01-22, [Fix `let_chains` and `if_let_guard` feature flags](rust-lang#93213) * On 2022-02-25, [Initiate the inner usage of `let_chains`](rust-lang#94376) * On 2022-01-28, [[WIP] Introduce ast::StmtKind::LetElse to allow the usage of `let_else` with `let_chains`](rust-lang#93437) * On 2022-02-26, [1 - Make more use of `let_chains`](rust-lang#94396) * On 2022-02-26, [2 - Make more use of `let_chains`](rust-lang#94400) * On 2022-02-27, [3 - Make more use of `let_chains`](rust-lang#94420) * On 2022-02-28, [4 - Make more use of `let_chains`](rust-lang#94445) * On 2022-02-28, [5 - Make more use of `let_chains`](rust-lang#94448) * On 2022-02-28, [6 - Make more use of `let_chains`](rust-lang#94465) * On 2022-03-01, [7 - Make more use of `let_chains`](rust-lang#94476) * On 2022-03-01, [8 - Make more use of `let_chains`](rust-lang#94484) * On 2022-03-01, [9 - Make more use of `let_chains`](rust-lang#94498) * On 2022-03-08, [Warn users about `||` in let chain expressions](rust-lang#94754) From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled. ## Divergent non-terminal matchers More specifically, rust-lang#86730. ```rust macro_rules! mac { ($e:expr) => { if $e { true } else { false } }; } fn main() { // OK! assert_eq!(mac!(true && let 1 = 1), true); // ERROR! Anything starting with `let` is not considered an expression assert_eq!(mac!(let 1 = 1 && true), true); } ``` To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider `let` an expression. It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers. ## Alternative syntax Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, `let PAT = EXPR` will be utilized for stabilization but it doesn't or shall create any obstacle for a **possible** future addition of `EXPR is PAT`. The introductory snippet would then be written as the following. ```rust if first_flower is Flower::Rose && first_flower_color is Color::Red && second_flower is Flower::Violet && second_flower_color is Color::Blue && pick_up_lines is &[first_pick_up_line, ..] { println!("Roses are red, violets are blue, {}", first_pick_up_line); } ``` Just to reinforce, this PR only unblocks a **possible** future road for `EXPR is PAT` and does emphasize what is better or what is worse. ## Tests * [Verifies the drop order of let chains and ensures it won't change in the future in an unpredictable way](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir/mir_let_chains_drop_order.rs) * [AST lowering does not wrap let chains in an `DropTemps` expression](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) * [Checks pretty printing output](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-pretty-check.rs) * [Verifies uninitialized variables due to MIR modifications](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs) * [A collection of statements where `let` expressions are forbidden](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/disallowed-positions.rs) * [All or at least most of the places where let chains are allowed](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs) * [Ensures that irrefutable lets are allowed in let chains](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs) * [issue-88498.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-88498.rs), [issue-90722.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-90722.rs), [issue-92145.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-92145.rs) and [issue-93150.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-93150.rs) were bugs found by third parties and fixed overtime. * [Indexing was triggering a ICE due to a wrongly constructed MIR graph](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/no-double-assigments.rs) * [Protects the precedence of `&&` in relation to other things](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/protect-precedences.rs) * [`let_chains`, as well as `if_let_guard`, has a valid MIR graph that evaluates conditional expressions correctly](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/then-else-blocks.rs) Most of the infra-structure used by let chains is also used by `if` expressions in stable compiler versions since rust-lang#80357 and rust-lang#88572. As a result, no bugs were found since the integration of rust-lang#88642. ## Possible future work * Let chains in match guards is implemented and working but stabilization is blocked by `if_let_guard`. * The usage of `let_chains` with `let_else` is possible but not implemented. Regardless, one attempt was introduced and closed in rust-lang#93437. Thanks `@Centril` for creating the RFC and huge thanks (again) to `@matthewjasper` for all the reviews, mentoring and MIR implementations. Fixes rust-lang#53667
Stabilize `let_chains` in Rust 1.64 # Stabilization proposal This PR proposes the stabilization of `#![feature(let_chains)]` in a future-compatibility way that will allow the **possible** addition of the `EXPR is PAT` syntax. Tracking issue: #53667 Version: 1.64 (beta => 2022-08-11, stable => 2022-10-22). ## What is stabilized The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example: ```rust pub enum Color { Blue, Red, Violet, } pub enum Flower { Rose, Tulip, Violet, } pub fn roses_are_red_violets_are_blue_printer( (first_flower, first_flower_color): (Flower, Color), (second_flower, second_flower_color): (Flower, Color), pick_up_lines: &[&str], ) { if let Flower::Rose = first_flower && let Color::Red = first_flower_color && let Flower::Violet = second_flower && let Color::Blue = second_flower_color && let &[first_pick_up_line, ..] = pick_up_lines { println!("Roses are red, violets are blue, {}", first_pick_up_line); } } fn main() { roses_are_red_violets_are_blue_printer( (Flower::Rose, Color::Red), (Flower::Violet, Color::Blue), &["sugar is sweet and so are you"], ); } ``` ## Motivation The main motivation for this feature is improving readability, ergonomics and reducing paper cuts. For more examples, see the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md). ## What isn't stabilized * Let chains in match guards (`if_let_guard`) * Resolution of divergent non-terminal matchers * The `EXPR is PAT` syntax ## History * On 2017-12-24, [RFC: if- and while-let-chains](rust-lang/rfcs#2260) * On 2018-07-12, [eRFC: if- and while-let-chains, take 2](rust-lang/rfcs#2497) * On 2018-08-24, [Tracking issue for eRFC 2497, "if- and while-let-chains, take 2](rust-lang/rust#53667) * On 2019-03-19, [Run branch cleanup after copy prop](rust-lang/rust#59290) * On 2019-03-26, [Generalize diagnostic for x = y where bool is the expected type](rust-lang/rust#59439) * On 2019-04-24, [Introduce hir::ExprKind::Use and employ in for loop desugaring](rust-lang/rust#60225) * On 2019-03-19, [[let_chains, 1/6] Remove hir::ExprKind::If](rust-lang/rust#59288) * On 2019-05-15, [[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains](rust-lang/rust#60861) * On 2019-06-20, [[let_chains, 3/6] And then there was only Loop](rust-lang/rust#61988) * On 2020-11-22, [Reintroduce hir::ExprKind::If](rust-lang/rust#79328) * On 2020-12-24, [Introduce hir::ExprKind::Let - Take 2](rust-lang/rust#80357) * On 2021-02-19, [Lower condition of if expression before it's "then" block](rust-lang/rust#82308) * On 2021-09-01, [Fix drop handling for `if let` expressions](rust-lang/rust#88572) * On 2021-09-04, [Formally implement let chains](rust-lang/rust#88642) * On 2022-01-19, [Add tests to ensure that let_chains works with if_let_guard](rust-lang/rust#93086) * On 2022-01-18, [Introduce `enhanced_binary_op` feature](rust-lang/rust#93049) * On 2022-01-22, [Fix `let_chains` and `if_let_guard` feature flags](rust-lang/rust#93213) * On 2022-02-25, [Initiate the inner usage of `let_chains`](rust-lang/rust#94376) * On 2022-01-28, [[WIP] Introduce ast::StmtKind::LetElse to allow the usage of `let_else` with `let_chains`](rust-lang/rust#93437) * On 2022-02-26, [1 - Make more use of `let_chains`](rust-lang/rust#94396) * On 2022-02-26, [2 - Make more use of `let_chains`](rust-lang/rust#94400) * On 2022-02-27, [3 - Make more use of `let_chains`](rust-lang/rust#94420) * On 2022-02-28, [4 - Make more use of `let_chains`](rust-lang/rust#94445) * On 2022-02-28, [5 - Make more use of `let_chains`](rust-lang/rust#94448) * On 2022-02-28, [6 - Make more use of `let_chains`](rust-lang/rust#94465) * On 2022-03-01, [7 - Make more use of `let_chains`](rust-lang/rust#94476) * On 2022-03-01, [8 - Make more use of `let_chains`](rust-lang/rust#94484) * On 2022-03-01, [9 - Make more use of `let_chains`](rust-lang/rust#94498) * On 2022-03-08, [Warn users about `||` in let chain expressions](rust-lang/rust#94754) From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled. ## Divergent non-terminal matchers More specifically, rust-lang/rust#86730. ```rust macro_rules! mac { ($e:expr) => { if $e { true } else { false } }; } fn main() { // OK! assert_eq!(mac!(true && let 1 = 1), true); // ERROR! Anything starting with `let` is not considered an expression assert_eq!(mac!(let 1 = 1 && true), true); } ``` To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider `let` an expression. It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers. ## Alternative syntax Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, `let PAT = EXPR` will be utilized for stabilization but it doesn't or shall create any obstacle for a **possible** future addition of `EXPR is PAT`. The introductory snippet would then be written as the following. ```rust if first_flower is Flower::Rose && first_flower_color is Color::Red && second_flower is Flower::Violet && second_flower_color is Color::Blue && pick_up_lines is &[first_pick_up_line, ..] { println!("Roses are red, violets are blue, {}", first_pick_up_line); } ``` Just to reinforce, this PR only unblocks a **possible** future road for `EXPR is PAT` and does emphasize what is better or what is worse. ## Tests * [Verifies the drop order of let chains and ensures it won't change in the future in an unpredictable way](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir/mir_let_chains_drop_order.rs) * [AST lowering does not wrap let chains in an `DropTemps` expression](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) * [Checks pretty printing output](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-pretty-check.rs) * [Verifies uninitialized variables due to MIR modifications](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs) * [A collection of statements where `let` expressions are forbidden](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/disallowed-positions.rs) * [All or at least most of the places where let chains are allowed](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs) * [Ensures that irrefutable lets are allowed in let chains](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs) * [issue-88498.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-88498.rs), [issue-90722.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-90722.rs), [issue-92145.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-92145.rs) and [issue-93150.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-93150.rs) were bugs found by third parties and fixed overtime. * [Indexing was triggering a ICE due to a wrongly constructed MIR graph](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/no-double-assigments.rs) * [Protects the precedence of `&&` in relation to other things](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/protect-precedences.rs) * [`let_chains`, as well as `if_let_guard`, has a valid MIR graph that evaluates conditional expressions correctly](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/then-else-blocks.rs) Most of the infra-structure used by let chains is also used by `if` expressions in stable compiler versions since rust-lang/rust#80357 and rust-lang/rust#88572. As a result, no bugs were found since the integration of rust-lang/rust#88642. ## Possible future work * Let chains in match guards is implemented and working but stabilization is blocked by `if_let_guard`. * The usage of `let_chains` with `let_else` is possible but not implemented. Regardless, one attempt was introduced and closed in rust-lang/rust#93437. Thanks `@Centril` for creating the RFC and huge thanks (again) to `@matthewjasper` for all the reviews, mentoring and MIR implementations. Fixes #53667
Can somebody explain to me why the Swift |
@alper It was considered and the community highly disliked it. There is literally a survey report inside the RFC document. |
πΌοΈ Rendered
β Tracking issue - Main
β Tracking issue - Edition transitioning
π Summary
Extends
if let
andwhile let
-expressions with chaining, allowing you to combine multiplelet
s andbool
-typed conditions together naturally. After implementing this RFC, you'll be able to write, among other things:The main aim of this RFC is to decide that this is a problem worth solving as well as discussing a few available options. Most importantly, we want to make
let PAT = EXPR && ..
a possible option for Rust 2018.π Thanks
To everyone who participated in RFC #2260 and to the survey participants.
To @scottmcm for collaborating with me on the original RFC.
To @aturon and @nikomatsakis for taking the time to discuss this with me.
To @SergioBenitez for checking the feasibility of this in Rust 2018.
To @oli-obk for providing me with the useful example in the summary ;)
To @joshtriplett for the consultation on the style.
To @kennytm for improving clarity on the Rust 2018 migration technical changes.