-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Result::and()
and Result::and_then()
could be generic over FromError
implementors
#18991
Comments
Result::and()
and Result::and_then()
should be generic over FromError
implementorsResult::and()
and Result::and_then()
could be generic over FromError
implementors
cc @aturon, this sounds like a good idea to me! |
@jakub- The blanket impl is already there, so it should be fine! This seems like a reasonable idea; my only worry is that it could cause trouble with type inference, because the additional flexibility means the method signature can't drive inference of the argument types. I'd suggest prototyping this change and seeing what the fallout (if any) looks like. |
I tried to track this down through git, but I couldn't quite figure it out. Did this end up happening or not? |
@steveklabnik Sadly not, busy times. :( There was a PR if anyone wants to pick this up and carry on: #19078. |
I'm going to close this for the time being (see this comment). We could certainly revisit it via an RFC later on. Thanks! |
Keep already computed inlay hint properties instead of late resolving them
The error interoperation RFC (rust-lang/rfcs#201) did not cover adapting the current APIs such as Result to be more general purpose with regards to the new
FromError
trait.It seems to me that the current signatures of
and
andand_then
:could now be:
to allow using these combinators in the same cross-boundary fashion as the
try!
macro.This would also require a blanket implementation of
FromError<E>
for any E.The text was updated successfully, but these errors were encountered: