Tracking issue for eRFC 2497, "if- and while-let-chains, take 2"

Centril commented 6 years ago

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:

[x] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
[ ] Adjust documentation (see instructions on forge)
[ ] Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
[ ] resolve expr fragment specifier issue (#86730)
[ ] Stabilization PR (see instructions on forge)

Unresolved questions:

[x] The final syntax
- This would benefit from a design note summarizing previous discussions on let as a boolean expression, and possibilities of is syntax.
[x] Should temporary and irrefutable lets without patterns be allowed in some form?
[ ] Chained if lets inside match arms

Collected issues:

Implementation history:

Unresolved problems

[ ] Can we be confident that the implementation is correct and well tested?

kristof-mattei commented 1 year 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 a bool, 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.

mark-i-m commented 1 year ago

I think people could reasonably interpret it either way, but it probably auto to be a warning or at least a clippy lint.

RealRTTV commented 1 year ago

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?

PoignardAzur commented 10 months ago

Any progress on this feature?

rami3l commented 10 months ago

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

est31 commented 10 months ago

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.

pnkfelix commented 9 months ago

re todo item "resolve expr fragment specifier issue", see also https://github.com/rust-lang/rfcs/pull/3531, "Macro matcher fragment specifiers edition policy".

photino commented 8 months ago

This feature is really helpful. Is it possible to use in the Edition 2024?

slanterns commented 8 months ago

It's not related to edition.

inquisitivecrystal commented 8 months ago

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.

sammysheep commented 6 months ago

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!

Noratrieb commented 6 months ago

@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.

est31 commented 6 months ago

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.

roylaurie commented 6 months ago

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.

jpmckinney commented 6 months ago

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.)

TennyZhuang commented 5 months ago

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.

CEbbinghaus commented 4 months ago

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).

Noratrieb commented 4 months ago

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.

rust-lang / rust

Tracking issue for eRFC 2497, "if- and while-let-chains, take 2" #53667