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
{{ message }}
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.
Use of nub at O(n^2) is nearly always a bug. I have both ordNub and hashNub defined in various places, both of which are substantially more useful. There's pretty much nothing that is just Eq.
I agree that nubOrd or nubHash should be used inetead, most of the time. Maybe offer this one as nubEq? Gives it less primacy.
Would this be in a typeclass? Some datatypes can implement nubEq quite efficiently, because they already use Ord or Hashable under the surface. For example, nubEq for a multi hash set could just visit each bucket and nub within the bucket.
@ndmitchell: Agreed. I was definitely considering the Hash variant one already, since I'm adding the hash interfaces now.
@mgsloan: yes, very likely be in a typeclass so that we can offer the family of nub function for unboxed array, boxed array, string, and list. And anything else that will come after that. probably a good idea to still provide a nubEq for some cases, and thus make it less prominent.
to
The text was updated successfully, but these errors were encountered: