-
Notifications
You must be signed in to change notification settings - Fork 605
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
Review TryFutureExt combinators #2470
Comments
Upon further consideration I have suggestions for combinator names. map_ok and map_err have excellent clarity, they obviously map the ok/err case in the chain. To instead of implying mapping a part imply conditionality one can take inspiration from and_then/or_else, arriving at: I am not truly happy with these names, since they don't really match the meanings in Result, but they are less breaking.
That change would then include removing .then from FutureExt, to maintain that .then implies returning a Result. The challenge is that futures-rs used Result as the basis of the future type itself before, meaning that these two corners of the top-post's table that are empty didn't exist. Now that the Future trait has been defined to return not only Results but any type new cases appear and trouble with them. As this means creating entirely new names I feel quite out of my depth. |
The alternate solution would be to wait for async closures to hit stable, remove the option of combining with synchronous functions altogether (as people can just as well use an async closure to wrap the function or make it async) and just run with the same methods as Result (excepting .map to .map_ok). |
Closing in favor of #2755. |
Currently there isn't a complete selection of sync/async and Result/infallible combinators in TryFutureExt.
For the times when one wants to convert an Ok result into an error depending on its value or vice versa sync combinators that return Result would be nicer than using FutureExt::map and only caring about one of the cases.
Likewise when one has an async function that is infallible, such as a web handler that in the worst case renders and returns an error page to treat the same as a successful result, infallible async combinators would be very helpful. Instead of declaring returning with Ok around the return and matching the unused Error type to the TryFuture::Error.
The text was updated successfully, but these errors were encountered: