Implement traits for Option
and Result
#57
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Values of types
Option
andResult
are frequently checked for equality in testing, butapprox
does not currently implement its traits on these types. This PR aims to do just that.For
Result<T, E>
I have opted to require the given trait on bothT
andE
, so that the error can also contain approximately comparable values. I'm not entirely sure about this decision, however, so I would appreciate your input. The downside of this approach is that all error types are also forced to implement the given trait, which might be asking too much of the users of this library - especially since there is no easy way (e.g.#[derive(...)]
) to do it automatically.It's worth noting that
(Result<T, E> as UlpsEq)::default_max_ulps
returns the maximum tolerance ofT
andE
. This is because the return type cannot be a tuple (unlikeAbsDiffEq
), and it seemed reasonable to allow the greater value. If anybody has a better idea - that doesn't involve breaking changes -, please let me know.I can separate the implementations of
Option
andResult
into separate PRs if necessary.