Tracking issue for eRFC 2497, "if- and while-let-chains, take 2" #53667
Comments
Centril
added
B-RFC-approved
|
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. |
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. |
|
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: #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
and others
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_chainsin Rust 1.64 #94927, reverted in Revert let_chains stabilization #100538Unresolved questions:
letas a boolean expression, and possibilities ofissyntax.if lets insidematcharmsCollected issues:
if let true = (false && true) {}#60336scrutinee: boolin if-to-match desugaring in match-expr typeck #60707if-without-else-as-fn-expr.rs#60254match $c { true => $i, _ => $e }is slow #60571if letwhen a failedifblock could be parsed as one #44990Implementation history:
x = ywhereboolis the expected type #59439Let(..)in AST, remove IfLet + WhileLet and parse let chains #60861hir::ExprKind::Let- Take 2 #80357ifexpression before it's "then" block #82308let_chainsworks withif_let_guard#93086let_chainsandif_let_guardfeature flags #93213lets in certain places #97295||in let chain expressions #94754let_elsedoes not interact withlet_chains#94974let_chains] Forbidletinside parentheses #95008||operators are not currently supported in let chain expressions #95314Unresolved problems
The text was updated successfully, but these errors were encountered: