-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 eRFC 2497, "if- and while-let-chains, take 2" #53667
Comments
I'm working on implementing this in a 3+ PR step fashion based on discussions with @oli-obk. |
for the record, the discussed step list is
|
I can't imagine 3 would be a particularly large step (enough to merit splitting), but 3 steps sounds fair enough. |
[WIP] [let_chains, 1/6] Remove hir::ExprKind::If Per #53667 (comment). r? @oli-obk
[let_chains, 1/6] Remove hir::ExprKind::If Per #53667 (comment). r? @oli-obk
[let_chains, 2/6] Introduce `Let(..)` in AST, remove IfLet + WhileLet and parse let chains Here we remove `ast::ExprKind::{IfLet, WhileLet}` and introduce `ast::ExprKind::Let`. Moreover, we also: + connect the parsing logic for let chains + introduce the feature gate + do some AST validation + rewire HIR lowering a bit. However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR. Per #53667 (comment). Next step after #59288. cc @Manishearth re. Clippy. r? @oli-obk
[let_chains, 2/6] Introduce `Let(..)` in AST, remove IfLet + WhileLet and parse let chains Here we remove `ast::ExprKind::{IfLet, WhileLet}` and introduce `ast::ExprKind::Let`. Moreover, we also: + connect the parsing logic for let chains + introduce the feature gate + do some AST validation + rewire HIR lowering a bit. However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR. Per #53667 (comment). Next step after #59288. cc @Manishearth re. Clippy. r? @oli-obk
[let_chains, 2/6] Introduce `Let(..)` in AST, remove IfLet + WhileLet and parse let chains Here we remove `ast::ExprKind::{IfLet, WhileLet}` and introduce `ast::ExprKind::Let`. Moreover, we also: + connect the parsing logic for let chains + introduce the feature gate + do some AST validation + rewire HIR lowering a bit. However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR. Per #53667 (comment). Next step after #59288. cc @Manishearth re. Clippy. r? @oli-obk
@Centril I'm really jazzed about this feature, lmk if there is any work I can help with. |
Yeah before we stabilize this we should in any case wait for the decision on that RFC, which in this instance can turn in any direction. |
I think this should keep moving forward. Why trash all of this work unless the other RFC actually gets accepted? The other idea has already been shot down before. The recent sentiment I've seen on Reddit and in the comments on Github don't paint a picture of anything changing in that regard. |
I also say keep moving forward. In terms of governance, I don’t think it makes sense to pause work on one RFC anytime another RFC suggests an alternative. That’ll just stall everything. (Also, that other RFC will not pause for this one.) |
I expect more arms to be added here later, but for the time being, let's address the clippy complaint and swap this to an if let. It would be nice if we could chain these ifs, it's not stabilized yet: rust-lang/rust#53667
I do not think rust-lang/rfcs#3573 should block this RFC. |
After reading rust-lang/rfcs#3573 I actually disagree with @TennyZhuang. The two features stand in opposition to one another as they both offer the same functionality. However the |
Please remember that tracking issues are not for discussion, but for updates, especially large ones like this one. Please open a new issue/Zulip/internals.rust-lang.org thread (that can be linked from here) to discuss the feature, so that people subscribed to the issue don't get spammed and the issue history remains readable. |
We talked about this in the lang planning meeting today. As far as we know, the blockers and semi-blockers to this have been resolved. E.g.:
At this point, we would encourage someone to write up a comprehensive stabilization report and include that in a PR proposing |
This is really wonderful news, @traviscross! I've went over the original stabilization PR (now reverted) and related issues to refresh my memory. I've found two possible stabilization blockers that I have opened zulip threads about.
As there is many people subscribed, please try to keep replies in the linked zulip threads. |
…compiler-errors Additional tests to ensure let is rejected during parsing In the original stabilization PR, @ `compiler-errors` has [pointed out](rust-lang#94927 (comment)) that rust-lang#97295 wasn't enough to address the concerns about having `let` in expressions being rejected at parsing time, instead of later. Thankfully, since then the situation has been greatly improved by rust-lang#115677. This PR adds some additional tests to `disallowed-positions.rs`, and adds two additional revisions to the "normal" case which is now given the `feature` name: * `no_feature`: Added to incorporate `disallowed-positions-without-feature-gate.rs` into the file, reducing duplication. * `nothing`: like feature, but all functions are cfg'd out. Ensures that the errors are really emitted during parsing. cc tracking issue rust-lang#53667
Stabilization report/PR: #132833 |
Rollup merge of rust-lang#132828 - est31:let_chains_parsing_tests, r=compiler-errors Additional tests to ensure let is rejected during parsing In the original stabilization PR, @ `compiler-errors` has [pointed out](rust-lang#94927 (comment)) that rust-lang#97295 wasn't enough to address the concerns about having `let` in expressions being rejected at parsing time, instead of later. Thankfully, since then the situation has been greatly improved by rust-lang#115677. This PR adds some additional tests to `disallowed-positions.rs`, and adds two additional revisions to the "normal" case which is now given the `feature` name: * `no_feature`: Added to incorporate `disallowed-positions-without-feature-gate.rs` into the file, reducing duplication. * `nothing`: like feature, but all functions are cfg'd out. Ensures that the errors are really emitted during parsing. cc tracking issue rust-lang#53667
…compiler-errors Additional tests to ensure let is rejected during parsing In the original stabilization PR, @ `compiler-errors` has [pointed out](rust-lang#94927 (comment)) that rust-lang#97295 wasn't enough to address the concerns about having `let` in expressions being rejected at parsing time, instead of later. Thankfully, since then the situation has been greatly improved by rust-lang#115677. This PR adds some additional tests to `disallowed-positions.rs`, and adds two additional revisions to the "normal" case which is now given the `feature` name: * `no_feature`: Added to incorporate `disallowed-positions-without-feature-gate.rs` into the file, reducing duplication. * `nothing`: like feature, but all functions are cfg'd out. Ensures that the errors are really emitted during parsing. cc tracking issue rust-lang#53667
This is a tracking issue for the eRFC "if- and while-let-chains, take 2" (rust-lang/rfcs#2497).
For the tracking issue for the immediate edition changes, see #53668.
Steps:
let_chains
in Rust 1.64 #94927, reverted in Revert let_chains stabilization #100538Unresolved questions:
let
as a boolean expression, and possibilities ofis
syntax.if let
s insidematch
armsCollected issues:
if let true = (false && true) {}
#60336scrutinee: bool
in if-to-match desugaring in match-expr typeck #60707if-without-else-as-fn-expr.rs
#60254match $c { true => $i, _ => $e }
is slow #60571if let
when a failedif
block could be parsed as one #44990Implementation history:
x = y
wherebool
is the expected type #59439Let(..)
in AST, remove IfLet + WhileLet and parse let chains #60861hir::ExprKind::Let
- Take 2 #80357if
expression before it's "then" block #82308let_chains
works withif_let_guard
#93086let_chains
andif_let_guard
feature flags #93213let
s in certain places #97295||
in let chain expressions #94754let_else
does not interact withlet_chains
#94974let_chains
] Forbidlet
inside parentheses #95008||
operators are not currently supported in let chain expressions #95314Unresolved problems
The text was updated successfully, but these errors were encountered: