-
Notifications
You must be signed in to change notification settings - Fork 789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing Nan=Nan behavior for Set and Map collection types #14515
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When it comes to NaNs in collections, we may want to discuss what we should treat as correct behaviour, since there are some more inconsistencies:
#13207
I am aware of that issue, that is more opinionated because it asks what the implicit default should be. In the case of functions, it is nothing to discuss - those are explicit and documented functions, which state what kind (nan=nan vs nan<>nan) is used internally. |
@T-Gro |
It would probably make sense for F# to match the .NET rules here, which is that
In general, |
Fixes #14507 bug .
Per documentation, GenericEqualityER "Compare two values for equality using equivalence relation semantics ([nan] = [nan])". It is a sibling to GenericEquality , which treats
nan<>nan
.This
nan=nan
behaviour GenericEqualityER in should work for structural data, incl. collections, unions, records etc.Summary of existing behavior for various types, when holding nan (or nanf):
Scalar value = OK
Lists = OK (generated code coming from DU implementation)
Array = OK (special-cased in Fsharp.Core)
Sets = GenericEqualityER behaves the same like GenericEquality , i.e.
set [nan] <> set [nan]
=> wrongMaps = fails just like it does for Sets, both for Keys and for values
An inconsistency between lists and Sets/Maps is considered a bug, because all 3 of them are typical F# constructs for data modelling.
The fact that they did not support GenericEqualityER out of the box was an implementation-detail-bug.
This PR addresses this by having both
Set<>
andMap<,>
implementinterface System.Collections.IStructuralEquatable
.For Maps, I decided to use the passed in comparer for both keys and values (one can argue about the logical validity of floats as keys in a map, but it is technically possible).