Following the structural model, users should be able to give epsilon variants that match the different enum branches:
assert_float_eq!(Ok(0.1), Ok(0.2), abs <= Ok(0.1)); // true
assert_float_eq!(Ok(0.1), Err(0.2), abs <= Ok(0.1)); // false
assert_float_eq!(Err(0.1), Err(0.2), abs <= Ok(0.1)); // false, epsilon is a different variant
assert_float_eq!(Err(0.1), Err(0.2), abs <= Err(0.1)); // true
// chaining allows multiple variants to be compared
assert_float_eq!(a, b, abs <= Ok(0.1), Err <= (0.1));
There is also the question of what to do where enums have branches that aren't floating point values. This would require a solution to https://github.com/jtempest/float_eq-rs/issues/10. It's likely that the common case of Result would be T of some float value and E of a non-float, but it's plausible that the opposite could be true or both could be float comparable. In this case, it might be nice to fall back on PartialEq - which might require specialisation or the implementation of default associated types in traits.
Following the structural model, users should be able to give epsilon variants that match the different enum branches:
There is also the question of what to do where enums have branches that aren't floating point values. This would require a solution to https://github.com/jtempest/float_eq-rs/issues/10. It's likely that the common case of Result would be T of some float value and E of a non-float, but it's plausible that the opposite could be true or both could be float comparable. In this case, it might be nice to fall back on PartialEq - which might require specialisation or the implementation of default associated types in traits.