Skip to content
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

Decide on generic-ness of functions like Iterator::try_find and array::try_map #85115

Closed
scottmcm opened this issue May 9, 2021 · 1 comment · Fixed by #91286
Closed

Decide on generic-ness of functions like Iterator::try_find and array::try_map #85115

scottmcm opened this issue May 9, 2021 · 1 comment · Fixed by #91286
Assignees
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@scottmcm
Copy link
Member

scottmcm commented May 9, 2021

array::try_map tracking issue: #79711
Iterator::try_find tracking issue: #63178

try_map only allows the closure to return a Result, and has the function also return a Result.
try_find was added in #63177 allowing the closure to return any Try (v1), but the function itself always returned a Result.

With Try v2, there's no longer an associated type for the Error type, so try_find needs a different approach. #84767 changed it to a bit of a hacky version that's probably not what should be stabilized. And whatever solution is picked should probably be used for try_map as well.

I think there are two main options:

  1. Support only Result. This is certainly the easiest option. It's unclear how important supporting other types would be -- this might depend on the error handling WG's work. If it ends up having a not-really-Result type that's used in some situations, this might be suboptimal.
  2. Treat residuals as a "family", and offer a trait that can be used to get the correct output type. There's a sketch of how this could look in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-try_find, with a prototype implementation in scottmcm@0b12d0d#diff-c552b2bf18fb3212fe93dd601ce487badf5e50faf9aeed4db7b0f6c22571ef01R2442 This is more complicated and may need an RFC, but is also the most general, with additional benefits elsewhere.
  3. Make the return type of the methods generic, so they're picked by the context of the caller. While this would work, I think the annotation burden would be frustrating -- .try_find(...)? wouldn't work, as ? isn't a strong enough context to force any particular family of types.
@scottmcm
Copy link
Member Author

scottmcm commented Dec 4, 2021

With #91286, this is now resolved using approach 2, via a Residual trait.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant