>
> > I have a different take on this. I think intersect() is by definition a
> > set operation and the method on Iterable is simply a convenience that
> > automatically converts the object and the arguments to sets. I would
> > even argue for the result of the method always being a set as well.
>
> If you argue like that I have to ask: Does it make sense to convert an
> Iterable to Set automatically? Wouldn't it be better to instead have it
> on Set only?
>
Probably. But a convenience method is normally there to remove the need for
boilerplate yourself, such as the conversions to sets.
Interestingly, Paul mentions on the corresponding issue that intersect()
was originally a convenience for
a.findAll { b.contains(it) }
I really wonder if we should keep the method on anything that is no
> Set... actually even with sets... If a non-standard comparator is used,
> problems like above will easily happen again.
>
equals() itself should be commutative, so only a broken implementation
would cause issues. That would then be the fault of the comparator
implementor.
I'd be happy to see the method deprecated and renamed if it's not intended
to be a set intersection. That would reduce or eliminate the confusion
without breaking any backwards compatibility.
Peter
