Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upBe 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. |
This comment has been minimized.
This comment has been minimized.
|
I came to think that this might break (undocumented?) runtime behavior for some. With the current code, the second test of |
This comment has been minimized.
This comment has been minimized.
Can't find that one. |
This comment has been minimized.
This comment has been minimized.
eNeRGy164
commented
Dec 10, 2019
|
This comment has been minimized.
This comment has been minimized.
|
Duh. Wasn't looking in the PR itself. |
This comment has been minimized.
This comment has been minimized.
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`.
This comment has been minimized.
This comment has been minimized.
|
I've updated the PR to use a white-list of numeric types, for which we will try conversion between. |
jnyrup
merged commit f2a5158
into
fluentassertions:master
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.
jnyrup commentedDec 8, 2019
•
edited
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