fn test(&mut self) -> Result<Option<Vec<Vec<Field<Type<'static>>>>>, Error> {
// branch 1
Ok(Some(data)) // data is the ugly structure above
// branch 2
Ok(None) // Totally fine, under certain conditions the function doesn't return data
}
Now in a function test I wanted to check the branch that returns no data:
let res = x.test().unwrap();
assert_eq!(res, None);
However, the compiler notices an error as follows:
binary operation == cannot be applied to type std::option::Option<std::vec::Vec<std::vec::Vec<lib::Field<lib::Type<'_>>>>>
Apart from the fact that the argument itself is incredibly ugly and may be solved more elegant, I don't get why the error is encountered here. I'm assuming this is totally expected when not implementing/deriving corresponding trait functionality when expecting and comparing said data structure as returning option, but assuring None should be totally fine, no?
If anyone could enlighten me that would be awesome!
For the None case you don’t need to use an equality test. You can just use assert!(matches!(res, None)), or (for the better error messages) use assert_matches!(res, None).
Good point about assert_matches!(res, None), didn't know about that one.
A side note, personally I avoid using assert!() since if it fails it doesn't tell you the actual value which more often than not provides details why something failed. In this case I'm not testing matches!() macro, I'm comparing expected and returned values of a function.
Most likely Field and Type need to implement Eq or PartialEq
Yes, this is true!
For the None case you don’t need to use an equality test. You can just use assert!(matches!(res, None))
Thanks, I also didn't know about this one!
That said, this indeed solves the problem (as it doesn't need that actual comparison).
Still curious what prevents the comparison. Relatively new to rust, so just wondering: Is this a general requirement to have all possible return values be comparable at compile time even for Option? Maybe I just falsely assumed that Option is an exception to this.
Yes.. well kinda yes. == actually belongs to PartialEq which does not need all values to be comparable. But indeed you can only use == on Option<T> if you can use it on T. Equality checks are a trait method like any other, there is no compiler magic in place to figure out “oh, it’s None, I know how to pattern match against that value instead of using PartialEq”.
Of course actual pattern matching still works without an PartialEq impl, hence matches!(val, pat), which is nothing more than an abbreviation of match val { pat => true, _ => false } does work. In the case of an Option, you could also use the method assert!(res.is_none()).