You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was surprised to find that the sort position of an element is also being used to determine element equality. This is can be seen with the following test case:
I would expect methods like remove(_ element: Element) to only remove if the elements are actually equal, not just if they're sorted into the same place. This method has the same signature as the one on Set, but behaves very differently.
A workaround is to define the sort function to take equality into account. I don't believe it's intuitive to consider objects sorted to the same index as also being Equal. At a minimum this should be better documented. I'd suggest to either update the functionality to take Equatable conformance into account, or change the method names to make it clear its acting on sort order not equality.
The text was updated successfully, but these errors were encountered:
I was surprised to find that the sort position of an element is also being used to determine element equality. This is can be seen with the following test case:
I would expect methods like
remove(_ element: Element)
to only remove if the elements are actually equal, not just if they're sorted into the same place. This method has the same signature as the one onSet
, but behaves very differently.A workaround is to define the sort function to take equality into account. I don't believe it's intuitive to consider objects sorted to the same index as also being Equal. At a minimum this should be better documented. I'd suggest to either update the functionality to take Equatable conformance into account, or change the method names to make it clear its acting on sort order not equality.
The text was updated successfully, but these errors were encountered: