-
Notifications
You must be signed in to change notification settings - Fork 14.1k
Rename and expose LoopState as ControlFlow #76204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,67 @@ | ||||||
| use crate::ops::Try; | ||||||
|
|
||||||
| /// Used to make try_fold closures more like normal loops | ||||||
| #[unstable(feature="control_flow_enum", reason="new API", issue="75744")] | ||||||
| #[derive(Debug, Clone, Copy, PartialEq)] | ||||||
|
||||||
| #[derive(Debug, Clone, Copy, PartialEq)] | |
| #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)] |
Hash and especially Eq seem handy, although they are not needed to replace LoopState and are less essential for ControlFlow than for Option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that seems sensible! I don't know when you'd want to hash this but I suppose there's no reason to prevent it.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have found that C = () is very common when using this enum, common enough that it might deserve a defaulted type parameter. We could add one backwards compatibly but only if C follows B in the parameter list. Otherwise we would have to default B at the same time and anyone that wishes to override it would have to override C as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be confusing to do this without changing the order of the variants as well, and we may as well do that too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On consideration, I think a separate PR would be best.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the second parameter be R::Error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, definitely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see - we can't do this because it's an unconstrained type parameter. Is there a good way to solve that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the break part here is intentionally the full impl Try type (Result, etc). They're definitely strange APIs, though -- break_value is something that could plausibly stabilize, but these ones probably aren't.
Maybe leave this particular impl block over in iter as non-pub so they can still be used there, but don't show up in the rustdoc? (And won't need #[unstable] since they'll be unusable outside iter.)
I've been contemplating making a pass through the implementations to use feature(try_blocks) instead of explicit Try::foo calls where possible; this PR going in would be a good impetus to go do that -- and hopefully delete these methods while I'm at it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see. I misunderstood how these were being used. You're right, it's a very strange API.

Uh oh!
There was an error while loading. Please reload this page.