-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
Tracking issue for ControlFlow enum, for use with try_fold and in Try #75744
Copy link
Copy link
Closed
Labels
A-control-flowArea: Control flowArea: Control flowA-iteratorsArea: IteratorsArea: IteratorsC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCLibs-TrackedLibs issues that are tracked on the team's project board.Libs issues that are tracked on the team's project board.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-control-flowArea: Control flowArea: Control flowA-iteratorsArea: IteratorsArea: IteratorsC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCLibs-TrackedLibs issues that are tracked on the team's project board.Libs issues that are tracked on the team's project board.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
(edited to turn this into a tracking issue, as it's referenced by the
unstableattributes)This is a tracking issue for the
std::ops::ControlFlowtype.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
Resultstry_trait_v2#84767Iterator::try_foldandIterator::try_for_eachUnresolved 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(probably not theRemoved those ones in Demoteinto_tryones, https://github.com/rust-lang/rust/pull/76204/files#r481515347)ControlFlow::{from|into}_trytopub(crate)#85645Are theCONTINUE/BREAKconstants valuable? See StabilizeControlFlow::{BREAK, CONTINUE}#102697ControlFlow::{BREAK, CONTINUE}#107398B = ()too? (Might be nice fortry_for_eachuses.)Implementation history
Initial PR that added
LoopStateas an implementation detail: #45595PR that exposed as unstable and renamed to
ControlFlow: #76204Added
BREAK/CONTINUEassociated constants: #76318Changed type parameter order and defaulted
C = (): #76614Add
is_breakandis_continuemethods: #78200I 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'sfold_whilefor short-circuiting functional-style loops over slices of our graphs, which is now deprecated in favor oftry_fold.try_foldis great, but the lack of a standard library providedTryimplementation 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 exposeLoopStateand provide an example in the docs.Originally related to: rust-itertools/itertools#469