-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Description
(edited to turn this into a tracking issue, as it's referenced by the unstable attributes)
This is a tracking issue for the std::ops::ControlFlow type.
The feature gate for the issue is #![feature(control_flow_enum)].
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
- Implement
- Block interconversion with
Results - Adjust documentation (see instructions on rustc-dev-guide)
- Stabilization PR (see instructions on rustc-dev-guide)
- As part of stabilizing, mention in the docs for
Iterator::try_foldandIterator::try_for_each
- As part of stabilizing, mention in the docs for
Unresolved Questions
-
Should we change the generic parameter order? https://github.com/rust-lang/rust/pull/76204/files#r481357223done in change the order of type arguments on ControlFlow #76614 - What methods make sense
-
(probably not theRemoved those ones in Demoteinto_tryones, https://github.com/rust-lang/rust/pull/76204/files#r481515347)ControlFlow::{from|into}_trytopub(crate)#85645
-
-
Are theCONTINUE/BREAKconstants valuable? See StabilizeControlFlow::{BREAK, CONTINUE}#102697 - Should it have
B = ()too? (Might be nice fortry_for_eachuses.)
Implementation history
Initial PR that added LoopState as an implementation detail: #45595
PR that exposed as unstable and renamed to ControlFlow: #76204
Added BREAK/CONTINUE associated constants: #76318
Changed type parameter order and defaulted C = (): #76614
Add is_break and is_continue methods: #78200
I work with an organization that has a large amount of Rust graph traversal code as part of its core business. We used to use itertools's fold_while for short-circuiting functional-style loops over slices of our graphs, which is now deprecated in favor of try_fold.
try_fold is great, but the lack of a standard library provided Try implementation that makes the loop semantics clear is confusing. We created our own, which is fine, but I think it would make a lot of sense to expose LoopState and provide an example in the docs.
Originally related to: rust-itertools/itertools#469