Stabilize ops::ControlFlow (just the type) by scottmcm · Pull Request #85608 · rust-lang/rust (original) (raw)

Tracking issue: #75744 (which also tracks items not closed by this PR).

With the new ? desugar implemented, it's no longer possible to mix Result and ControlFlow. (At the time of making this PR, godbolt was still on the 2021-05-01 nightly, where you can see that the mixing example compiled.) That resolves the only blocker I know of, so I'd like to propose that ControlFlow be considered for stabilization.

Its basic existence was part of rust-lang/rfcs#3058, where it got a bunch of positive comments (examples 1 2 3 4). Its use in the compiler has been well received (#78182 (comment)), and there are ecosystem updates interested in using it (rust-itertools/itertools#469 (comment), jonhoo/rust-imap#194).

As this will need an FCP, picking a libs member manually:
r? @m-ou-se

Stabilized APIs

#[derive(Debug, Clone, Copy, PartialEq)] pub enum ControlFlow<B, C = ()> { /// Exit the operation without running subsequent phases. Break(B), /// Move on to the next phase of the operation as normal. Continue(C), }

As well as using ? on a ControlFlow<B, _> in a function returning ControlFlow<B, _>. (Note, in particular, that there's no From::from-conversion on the Break value, the way there is for Errs.)

Existing APIs not stabilized here

All the associated methods and constants: break_value, is_continue, map_break, CONTINUE, etc.

Some of the existing methods in nightly seem reasonable, some seem like they should be removed, and some need more discussion to decide. But none of them are essential, so as in the RFC, they're all omitted from this PR.

They can be considered separately later, as further usage demonstrates which are important.