Open duponter opened 1 month ago
It makes sense to me. I'd like to get @mohrezaei's opinion too since there was a similar change in #1661 that raised performance concerns.
So clearly the behavior and the doc are inconsistent. It should be noted that this can only happen if the set's sense of equality is different from whatever way the returned set's elements are being compared to elements from this
.
So there are two ways to fix this: 1) Keep the doc, change the behavior. This would get rid of the optimization. 2) Keep the behavior, fix the doc.
I would generally favor (2), for the following reasons:
intersect
, difference
, etc) are borrowed from set-theory, where set elements don't have different senses of equality.We could even be very explicit in the doc and suggest using this.select(that.contains)
if someone has the requirement to preserve the memory references from this
.
Context
According to the JavaDocs
SortedSet#intersect
should always return members from this:https://eclipse.dev/collections/javadoc/11.1.0/org/eclipse/collections/api/set/sorted/ImmutableSortedSet.html#intersect(org.eclipse.collections.api.set.SetIterable)
Issue
However, testing reveals that elements of the smallest of the 2 sets are returned instead. Not only contradicts this the API documentation, but this is counterintuitive as well. In addition, when replacing
intersect
with theselect(Set::contains)
combination, the same functionality works as expected.Reproduction
Following test suite contains 4 test cases:
Technologies used: