Bug: Intersect should only return distinct values

[ghostsquad]

Lodash describes this operation as returning unique entries https://lodash.com/docs/#intersection

Also described in SQL: https://www.postgresql.org/docs/9.4/queries-union.html

INTERSECT returns all rows that are both in the result of query1 and in the result of query2. Duplicate rows are eliminated unless INTERSECT ALL is used.

EXCEPT returns all rows that are in the result of query1 but not in the result of query2. (This is sometimes called the difference between two queries.) Again, duplicates are eliminated unless EXCEPT ALL is used.

https://docs.microsoft.com/en-us/sql/t-sql/language-elements/set-operators-except-and-intersect-transact-sql?view=sql-server-ver15

[samber]

So you are suggesting renaming Intersect into IntersectAll then adding Intersect that returns unique values?

Looks good.

Those intersection helpers are getting a little bit complicated. I think we should use the same naming as SQL. What about coding some LeftJoin, InnerJoin, FullOuterJoin...

I am also wondering if we should accept variadic arguments? Such as Intersect(collection1, collection2, collection3, collection4)

[ghostsquad]

Ya, I like intersect, and intersectAll.

Variadic args seems useful. I'll update/create some more PRs

[wirekang]

This bug should be fixed.

[THOUSAND-SKY]

Changing what the function fundamentally does, without changing the signature, is going to cause grievances that will not be caught by the compiler, for the current consumers.

[ghostsquad]

Changing what the function fundamentally does, without changing the signature, is going to cause grievances that will not be caught by the compiler, for the current consumers.

Bugfixes change behavior. That's by design.

The expectation of this function, as mentioned in the description/commit message is that lodash intersect returns unique results. intersect in SQL also returns unique results. This should not differ from the current established expectations.