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

Closed
ghost opened this issue Nov 15, 2014 · 5 comments
Closed

Comments

@ghost
Copy link

ghost commented Nov 15, 2014

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 and and_then:

fn and<U>(self, res: Result<U, E>) -> Result<U, E>
fn and_then<U>(self, op: |T| -> Result<U, E>) -> Result<U, E>

could now be:

fn and<U, F: FromError<E>>(self, res: Result<U, F>) -> Result<U, F>
fn and_then<U, F: FromError<E>>(self, op: |T| -> Result<U, F>) -> Result<U, F>

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.

@ghost ghost changed the title Result::and() and Result::and_then() should be generic over FromError implementors Result::and() and Result::and_then() could be generic over FromError implementors Nov 15, 2014
@alexcrichton
Copy link
Member

cc @aturon, this sounds like a good idea to me!

@aturon
Copy link
Member

aturon commented Nov 16, 2014

@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.

@steveklabnik
Copy link
Member

I tried to track this down through git, but I couldn't quite figure it out. Did this end up happening or not?

@ghost
Copy link
Author

ghost commented Jan 29, 2015

@steveklabnik Sadly not, busy times. :( There was a PR if anyone wants to pick this up and carry on: #19078.

@aturon
Copy link
Member

aturon commented Feb 16, 2015

I'm going to close this for the time being (see this comment). We could certainly revisit it via an RFC later on. Thanks!

@aturon aturon closed this as completed Feb 16, 2015
lnicola pushed a commit to lnicola/rust that referenced this issue Jan 27, 2025
Keep already computed inlay hint properties instead of late resolving them
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants