-
Notifications
You must be signed in to change notification settings - Fork 20
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
ACP: impl From<Infallible> for io::Error
#86
Comments
Actually, same applies to |
it is not obvious to me, can you spell it out? |
fn from(infallible: Infallible) -> Error {
match infallible {}
} |
If I follow your logic, then This makes me think that I am not understanding your logic, which is why I’d appreciate if you could clarify the rationale. |
Note that we do have There is also |
@shepmaster actually, yes!
|
We talked about this in the libs meetup. Initially there was some support for this, but we were hesitant about the effect this would have on the ecosystem in pushing people to add lots of these impls. We continue to hope that rust-lang/rust#64715 (and the stabilization of ! itself) might happen eventually (and we've poked for an update on the status of that). Meanwhile, we're going to close this.. |
Proposal
Problem statement
Generic code sometimes needs to unify error types. This may happen in combinators or specialization-like wrappers. While
Infallible
should be obviously, trivially convertible toio::Error
, the impl is not available.Motivation, use-cases
My current use case (simplified)
Potential other use cases
I vaguely remember doing something like this in the past, I think it was related to
futures
or some IO:This allows unifying error types of different operations. If one of the operations is infallible and the other may return
io::Error
unify
currently can not be used even though it looks like it should.Solution sketches
Proposed solution: Impl conversion by matching on
self
, I don't see any downsides besides few added lines of codeAlternative solution 1:
impl<T> From<Infallible> for T
- this is probably far away due to overlap withimpl<T> From<T> for T
; the proposed solution already provides value and can be replaced with this alternative later without breaking anythingAlternative solution 2: do nothing, users can have their own
IntoIoError
trait (my current workaround) - this needlessly duplicates and complicates users code, adding a few lines tostd
seems to be a better trade-off.Links and related work
PR implementing this
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.
The text was updated successfully, but these errors were encountered: