Be more strict when trying to convert types in IsSameOrEqualTo #1202
Conversation
Cool. I was planning to fix this thing in the same way this weekend.
|
I came to think that this might break (undocumented?) runtime behavior for some. With the current code, the second test of |
Can't find that one. |
|
|
Duh. Wasn't looking in the PR itself. |
Maybe we should be much more restrictive in what we consider equal. In other words, list the types for which we apply the rules. |
When comparing whether two objects are equal, a conversion should be precision preserving. Two examples of comparisons that currently unexpectedly passes: * `10` is not equal to `true` even though `10` is convertible to `true` as `true` is not convertible to `10`. * `0.02` is not equal to `0`, as that is due to truncation when converting the `double` into an `int`.
|
I've updated the PR to use a white-list of numeric types, for which we will try conversion between. |
Before fluentassertions#1202 we had an asymmetry where: * `When_comparing_an_enum_and_a_numeric_for_equality_it_should_not_throw` passed, but * `When_comparing_a_numeric_and_an_enum_for_equality_it_should_not_throw` failed. After fluentassertions#1202 both of them failed. This PR makes them both pass to minimize the change of behavior while fixing the asymmetry. fluentassertions#1204 has a discussion of how to compare enums, integers and strings.
When comparing whether two objects are equal, a conversion should be precision preserving.
Two examples of comparisons that currently unexpectedly passes:
10is not equal totrueeven though10is convertible totrueastrueis not convertible to10.0.02is not equal to0, as that is due to truncation when converting thedoubleinto anint.This fixes #1010
This fixes #1183