-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 2294, "if let guard" #51114
Comments
refactor match guard This is the first step to implement RFC 2294: if-let-guard. Tracking issue: #51114 The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers. r? @petrochenkov
👋 After a conversation about this change with @varkor I'm starting to take a look at this with a view to implementing it! |
@imjacobclark Hey. Any progress over the past few months? :-) |
Just ran into a case where this ability would be useful. I look forward to this feature landing someday! |
+1 This would be a nice feature to have! |
Remove `ast::Guard` With the introduction of `ast::ExprKind::Let` in #60861, the `ast::Guard` structure is now redundant in terms of representing [`if let` guards](#51114) in AST since it can be represented by `ExprKind::Let` syntactically. Therefore, we remove `ast::Guard` here. However, we keep `hir::Guard` because the semantic representation is a different matter and this story is more unclear right now (might involve `goto 'arm` in HIR or something...). r? @petrochenkov
…rochenkov Remove `ast::Guard` With the introduction of `ast::ExprKind::Let` in rust-lang#60861, the `ast::Guard` structure is now redundant in terms of representing [`if let` guards](rust-lang#51114) in AST since it can be represented by `ExprKind::Let` syntactically. Therefore, we remove `ast::Guard` here. However, we keep `hir::Guard` because the semantic representation is a different matter and this story is more unclear right now (might involve `goto 'arm` in HIR or something...). r? @petrochenkov
Remove `ast::Guard` With the introduction of `ast::ExprKind::Let` in #60861, the `ast::Guard` structure is now redundant in terms of representing [`if let` guards](#51114) in AST since it can be represented by `ExprKind::Let` syntactically. Therefore, we remove `ast::Guard` here. However, we keep `hir::Guard` because the semantic representation is a different matter and this story is more unclear right now (might involve `goto 'arm` in HIR or something...). r? @petrochenkov
Am currently learning Rust and thought it was unintuitive that I couldn't write this syntax. (Thought I must be mis-writing it somehow.) Lo, here it is in progress! Woo~ |
Any update on this? :) |
I was willing to take a look at this, but I didn't have time to... I'll try to free some time for this ASAP! |
Is the code here supposed to work? I would expect only direct use of a let expression (or maybe a chain with && if if let chains is also enabled) to be accepted. edit: Looks like it's not intended to be allowed (and was fixed by #111841) |
…r=cjgillot Add more tests for if_let_guard Adds tests for borrow checking, name shadowing and interaction with macros. cc rust-lang#51114
…, r=cjgillot Make if let guard parsing consistent with normal guards - Add tests that struct expressions are not allowed in `if let` and `while let` (no change, consistent with `if` and `while`) - Allow struct expressions in `if let` guards (consistent with `if` guards). r? `@cjgillot` Closes rust-lang#93817 cc rust-lang#51114
…r=cjgillot Make if let guard parsing consistent with normal guards - Add tests that struct expressions are not allowed in `if let` and `while let` (no change, consistent with `if` and `while`) - Allow struct expressions in `if let` guards (consistent with `if` guards). r? `@cjgillot` Closes rust-lang#93817 cc rust-lang#51114
…ests, r=compiler-errors Add more if let guard tests cc rust-lang#51114
Rollup merge of rust-lang#115965 - matthewjasper:extra-if-let-guard-tests, r=compiler-errors Add more if let guard tests cc rust-lang#51114
…guards, r=b-naber Capture scrutinee of if let guards correctly Previously we were always capturing by value. cc rust-lang#51114
Rollup merge of rust-lang#115999 - matthewjasper:closure-capture-let-guards, r=b-naber Capture scrutinee of if let guards correctly Previously we were always capturing by value. cc rust-lang#51114
I opened #118726 with a pretty-printer fix that is relevant to "if let guard". The rules for when struct literals must be enclosed in parentheses are different between if-let-guard and ordinary if-let. #![feature(if_let_guard)]
macro_rules! stringify_expr {
($expr:expr) => {
stringify!($expr)
};
}
macro_rules! stringify_if_let {
($expr:expr) => {
stringify_expr!(if let _ = $expr {})
};
}
macro_rules! stringify_if_let_guard {
($expr:expr) => {
stringify_expr!(match () { _ if let _ = $expr => {} })
};
}
fn main() {
println!("{}", stringify_if_let!(Struct {}));
println!("{}", stringify_if_let_guard!(Struct {}));
}
if let _ = (Struct {}) {}
match () { _ if let _ = Struct {} => {} } |
…r=TaKO8Ki Give temporaries in if let guards correct scopes Temporaries in if-let guards have scopes that escape the match arm, this causes problems because the drops might be for temporaries that are not storage live. This PR changes the scope of temporaries in if-let guards to be limited to the arm: ```rust _ if let Some(s) = std::convert::identity(&Some(String::new())) => {} // Temporary for Some(String::new()) is dropped here ^ ``` We also now deduplicate temporaries between copies of the guard created for or-patterns: ```rust // Only create a single Some(String::new()) temporary variable _ | _ if let Some(s) = std::convert::identity(&Some(String::new())) => {} ``` This changes MIR building to pass around `ExprId`s rather than `Expr`s so that we have a way to index different expressions. cc rust-lang#51114 Closes rust-lang#116079
This is a tracking issue for the RFC "if let guard" (rust-lang/rfcs#2294).
Steps:
Unresolved questions:
if
guard ones that testif let
guard insteadif
andif let
guards.if
guards behavior w.r.t. move semantics, I do not think that should hold up stabilizing this feature. We can just file an issue that those things need to be documented.)let else
were implemented but had problems discovered relatively late with their handling of certain details w.r.t. locals and temporary r-values is a hint that we may need to revisit our approach to testing features like this more broadly, in terms of how we advise implementors of such features on how to probe for such cases (and maybe also in the form of some kind of language-oriented test-generation tooling?)The text was updated successfully, but these errors were encountered: