Open Centril opened 6 years ago
I am not sure it has been discussed before, and I know it's a syntax which shouldn't be used, but isn't that a bit confusing?
let condition = false; let some_other_condition = false; if let false = condition && some_other_condition { println!("step 1"); // Does not enter here } if let false = (condition && some_other_condition) { println!("step 2"); // Enters here }
The first notation is ambiguous, and maybe not everyone expect the precedence to go that way. At least, there should be some kind of warning, like “You better write it that way:
if !condition && some_other_condition { … }
if that's what you meant”. That warning may even be shown whenever one pattern matches abool
, regardless of the context.
Correct me if I'm wrong but the way I read the let
statement is as follows: does the pattern match? let false = false
matches. Just like let None = None
. So now we have true && some_other_condition
, which is false
so we don't enter the if
statement.
For the second one we have (false && false)
, which is false
which matches the let false = false
predicate.
I think people could reasonably interpret it either way, but it probably auto to be a warning or at least a clippy lint.
Given that without let chains, the only syntactically valid code snippet is the second one, that to not cause breaking changes the only way is to make the first example the correct one?
Any progress on this feature?
Any progress on this feature?
@PoignardAzur AFAIK this feature is still blocked on https://github.com/rust-lang/rust/issues/103476.
A simple ping in this case does nothing. If you'd like to see this feature stabilized, I recommend you to:
try out let chains in your own code, and report bugs you find.
Originally posted by @est31 in https://github.com/rust-lang/rust/issues/103476#issuecomment-1338322481
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 https://github.com/rust-lang/rust/pull/107251#issuecomment-1779644448, 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 https://github.com/rust-lang/rfcs/pull/3531, "Macro matcher fragment specifiers edition policy".
This feature is really helpful. Is it possible to use in the Edition 2024?
It's not related to edition.
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.
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 https://github.com/rust-lang/rfcs/pull/3573 and it is not clear whether it makes sense to have both features (I personally don't think so). If it was decided that this should be stabilized (either because the RFC is rejected or because the lang team would like to have both), then it would need someone familiar with the let chains implementation to confirm that they are confident the implementation is correct now.
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.
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 do not think rust-lang/rfcs#3573 should block this RFC. is
operator is an alternative to the existing feature if let
, but not let-chains
. The motivation of the new is
operator is better readability from a left-to-right style, which means that it should also replace existing if let Some(x) = y
to if y is Some(x)
. Regardless of whether the is
operator is a more reasonable expression, we cannot remove the existing if let
style, so extending it is still meaningful.
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 is
operator is significantly more flexible and consistent due to it returning a boolean which lets it fit anywhere a boolean can. Currently the only thing that cannot be achieved any other way is chaining pattern matching which this RFC addresses. As such if this RFC makes it to stable then there is 0 functional reason to add is
, only ergonomic reasons (which already has a vocal opposition).
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. I want to avoid locking the issue so that people can post links to discussion.
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:
Implementation history:
Unresolved problems