-
Notifications
You must be signed in to change notification settings - Fork 13.3k
gate let_chains
in all places before the 2024 edition
#140198
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
base: master
Are you sure you want to change the base?
Conversation
Since `let_chains` relies on the 2024 edition drop order to be consistent, it makes sense for us to gate it in all places, even when there are unstable features such as with `if_let_guard`s in matches. This removes the need for us to pass in an enum to `CondChecker` as we can just always pass in the edition instead.
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
The job Click to see the possible cause of the failure (guessed by this bot)
|
= help: add `#![feature(let_chains)]` to the crate attributes to enable | ||
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date | ||
|
||
error[E0658]: `let` expressions in this position are unstable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this fine in the 2024 edition? If so it should say that rather than it being unstable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's due to the way #132833 was done: it just exempted 2024 usages from the feature gate instead of stabilizing the feature gate and adding an edition dependent error. I left that for future work, as I didn't know when it would stabilize. Plus, I saw that a lot of compiler crates were using let chains and I didn't want to play catch up with all the #![feature(let_chains)]
changes happening that occur as the compiler does changes naturally (knowing that the stabilization would likely take months).
Same goes for |
@rustbot labels +I-lang-nominated Let's vibe check on the lang call the direction we want to go here. |
@rustbot labels -I-lang-nominated We discussed this today. Our general policy is to prefer consistency between editions over consistency within an edition, so our appetite was in favor of allowing what can be allowed in older editions. We should of course ensure the diagnostics in the older editions are helpful in mitigating the surprise this may cause, e.g. by having the errors note when something needs an edition bump. The stabilizations for this will of course need our FCP. |
Since
let_chains
relies on the 2024 edition drop order to be consistent, it makes sense for us to gate it in all places, even when there are unstable features such as withif_let_guard
s in matches. This removes the need for us to pass in an enum toCondChecker
as we can just always pass in the edition instead.cc @est31