Stabilize ControlFlow::{BREAK, CONTINUE}

[scottmcm]

I don't think these ever had any libs-api oversight, but they're super-simple so I figured I'd just send this PR to prompt discussion.

I wasn't confident in them when I first added them (#76318 (comment)), but they've been extensively used in the compiler, and #75744 (comment) got posted in their favour. So that makes me think they're worth having. Here's a few examples:

rust/compiler/rustc_middle/src/ty/visit.rs

Lines 645 to 649 in d8613f7

	if predicate.flags().intersects(self.flags) {
	ControlFlow::Break(FoundFlags)
	} else {
	ControlFlow::CONTINUE
	}

rust/compiler/rustc_middle/src/ty/sty.rs

Lines 1897 to 1899 in d8613f7

	fn visit_ty(&mut self, t: Ty<'tcx>) -> ControlFlow<Self::BreakTy> {
	if self.0 == t { ControlFlow::BREAK } else { t.super_visit_with(self) }
	}

rust/compiler/rustc_data_structures/src/graph/iterate/mod.rs

Lines 347 to 352 in d8613f7

	) -> ControlFlow<Self::BreakVal> {
	match prior_status {
	Some(NodeStatus::Visited) => ControlFlow::BREAK,
	_ => ControlFlow::CONTINUE,
	}
	}

I think that ControlFlow::CONTINUE is particularly justified because the Continue generic parameter is defaulted to (). And if that constant exists, I think there might as well be BREAK to go with it. It's useful too, for any situation in which you're replacing bool with ControlFlow<()> in chain-of-responsibility style code, or similar.

@rustbot label +needs-fcp +T-libs-api -T-libs

cc the tracking issue #75744, though this is only a partial stabilization so this does not close that.

[scottmcm]

I flipped a coin between libs-api reviewers and got
r? @m-ou-se

[m-ou-se]

These feel a bit odd to me. I agree Continue(()) is often a useful value, but so is Ok(()) for which we also don't have an OK const.

[joshtriplett]

@m-ou-se I had the same reaction. I would lean against adding these.

[afetisov]

Personally I wouldn't be comfortable directly using them, unless they're part of the prelude. This looks like a feature too niche to just import directly. But if one uses them via the qualified name ControlFlow::BREAK/CONTINUE, then there is little value over the ordinary enum variant constructors.

[scottmcm]

Hi libs-api! This has been in limbo for a while, so I'm nominating to get a quorum input on what I should do with it.

Please either:

1. start fcp on it, or
2. say that, as the team, you'd like the constants to be removed instead, at which point I'll send a review to remove these.

(Or if there's some other process you'd like me to follow, let me know.)

[joshtriplett]

@scottmcm We discussed this in today's @rust-lang/libs-api meeting, and the general consensus was that we don't want to stabilize these, and we'd like to see them removed. Same argument as not adding OK for Ok(()).

@rfcbot close

[rfcbot]

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[scottmcm]

I removed a bunch of uses of these in #107023; PR to remove them completely is up as #107398.