-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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. |
Any progress on this feature? |
@PoignardAzur AFAIK this feature is still blocked on #103476. A simple ping in this case does nothing. If you'd like to see this feature stabilized, I recommend you to:
Originally posted by @est31 in #103476 (comment) |
The main/only blocker at this point that I see is #104843, for which there is #107251, which is blocked on a nice overview comment as asked for in #107251 (comment), then an FCP. At this point, I don't think that #103476 is a blocker any more, as enough time has passed. For #104893, I think due to the passage of time more people have tried out let chains, at least grep.app shows plenty of users. I don't really think it's much of a blocker either at this point any more. |
re todo item "resolve expr fragment specifier issue", see also rust-lang/rfcs#3531, "Macro matcher fragment specifiers edition policy". |
This feature is really helpful. Is it possible to use in the Edition 2024? |
Hi! No, I'm afraid not. Editions have to do with changes that might break old code; as far as I know, this is completely unrelated. Also, people generally prefer that this sort of question not be asked on the tracking issue, as it sends a notification out to everyone subscribed to the thread without providing new information. It's no big deal, just something to be careful about going forward. I believe the current status is described in est31's last post above. |
error: expected expression, found `let` statement --> src/common/run.rs:65:5 | 65 | let train_result = do_training(&mut storage); | ^^^ error: expected expression, found statement (`let`) --> src/common/run.rs:65:5 | 65 | let train_result = do_training(&mut storage); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: variable declaration using `let` is a statement error[E0425]: cannot find function `train_on_example` in this scope --> src/common/run.rs:30:15 | 30 | match train_on_example(storage, &proposition, &backlinks) { | ^^^^^^^^^^^^^^^^ not found in this scope | help: consider importing this function | 1 | use crate::model::maxent::train_on_example; | error[E0658]: `let` expressions in this position are unstable --> src/common/run.rs:65:5 | 65 | let train_result = do_training(&mut storage); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #53667 <rust-lang/rust#53667> for more information warning: unused import: `super::choose::compute_backlinks` --> src/model/maxent.rs:8:5 | 8 | use super::choose::compute_backlinks; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: unused import: `initialize_weights` --> src/model/maxent.rs:11:58 | 11 | use super::weights::{negative_feature, positive_feature, initialize_weights}; | ^^^^^^^^^^^^^^^^^^ error[E0308]: mismatched types --> src/common/run.rs:27:43 | 27 | let backlinks = compute_backlinks(storage, &proposition)?; | ----------------- ^^^^^^^ types differ in mutability | | | arguments to this function are incorrect | = note: expected mutable reference `&mut Storage` found reference `&Storage` note: function defined here --> src/model/choose.rs:74:8 | 74 | pub fn compute_backlinks( | ^^^^^^^^^^^^^^^^^ 75 | storage: &mut Storage, | --------------------- error[E0061]: this function takes 2 arguments but 1 argument was supplied --> src/common/run.rs:65:24 | 65 | let train_result = do_training(&mut storage); | ^^^^^^^^^^^ ------------ an argument of type `Box<(dyn LogicalModel + 'static)>` is missing | note: function defined here --> src/common/run.rs:12:8 | 12 | pub fn do_training(model:Box<dyn LogicalModel>, storage: &Storage) -> Result<(), Box<dyn Error>> { | ^^^^^^^^^^^ --------------------------- ----------------- help: provide the argument | 65 | let train_result = do_training(/* Box<(dyn LogicalModel + 'static)> */, &mut storage);
Nightly user here. My experience with this feature has been very good. I'm surprised with how concisely I can convey my intent. I find I tend to use chains with 3 clauses for some reason, and the succinct transitive nature of it feels elegant. 10/10. Would recommend! |
@joshtriplett has opened rust-lang/rfcs#3573 and it is not clear whether it makes sense to have both features (I personally don't think so). |
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. |
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:
Unresolved 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: