-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExceptBy doesn't include duplicates by comparer in first set that should not be excluded #7656
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @dotnet/area-system-linq Issue DetailsDescriptionIf the first set has duplicates according to the comparer function, the second one is removed from the resulting set, thus being an error. Reproduction StepsIf you have something like this:
Expected behavior
Actual behavior
Regression?No response Known Workarounds
Configuration.NET 6.0.101 Other informationThe code in Except.cs (line 94) uses a HashSet, thus eliminating the duplicates due to the comparer, which are not real duplicates
|
If your use case requires retaining duplicates, you should use @stephentoub |
|
Yes, a remarks section elaborating a bit more on what "set semantics" means in this case might be warranted (and in particular, how the projector delegate modulates the definition of the source set) might be warranted. Moving to dotnet-api-docs. |
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @dotnet/area-system-linq Issue DetailsDescriptionIf the first set has duplicates according to the comparer function, the second one is removed from the resulting set, thus being an error. Reproduction StepsIf you have something like this:
Expected behavior
Actual behavior
Regression?No response Known Workarounds
Configuration.NET 6.0.101 Other informationThe code in Except.cs (line 94) uses a HashSet, thus eliminating the duplicates due to the comparer, which are not real duplicates
|
I wasted a ton of time trying to hunt down why duplicate elements were missing after |
When using filters like `exclude`, it was possible for terms to not get synced when they should have. This was due to a misunderstanding of how `ExceptBy()` and `IntersectBy()` work. According to [an issue][1] on the dotnet runtime repo, this is by design. The fix is to just avoid those in favor of `Where()`. Fixes #69. [1]: dotnet/dotnet-api-docs#7656
@rcdailey - See the "Set Operations" link in my earlier comment. That aside, probably the largest mainstream use of set mathematics in programming (and possibly the originator?) is SQL; the primary reason for |
I saw the link, although admittedly I am uninterested in it. Mathematics stuff isn't my deal. My misunderstanding was that
No where is it mentioned that duplicates are filtered out. Even the graphical example lacks this. Every example I see out there has no duplicate keys. So I think it's understandable that:
I understand that what you are describing is "technically correct", but that's not always the best kind of correct. I prefer straightforward documentation that explains things in a way that makes sense from a programming standpoint: That is, pre-conditions and post-conditions clearly explained. What we have instead is something more akin to what I'd find in a college math book, which I personally find less intuitive. Maybe I'm alone on this. But that's my feedback on the matter. |
Yes, that's why this issue is still open - as stated earlier, the documentation should be updated. |
This is clearly a bug. Can anyone come up with any use case solved by the current implementation? The implementation that makes sense, though, the one where the distinct operation is made on the final set, not on the key - that solves a very common use case: to filter a list based on a blacklisted property. |
That presumes that elements have some equatable key, outside of the one used for the call to Besides the fact that changing this behavior would be an insanely massive breaking change. If you want the behavior you're thinking of, the |
I just encountered this behavior, with all duplicates removed. Maybe @IEvangelist could help? He edited the documentation and provided code in 2021. |
Sure, see dotnet/docs#39182 |
Thanks @IEvangelist! |
Description
If the first set has duplicates according to the comparer function, the second one is removed from the resulting set, thus being an error.
The resulting set should include all duplicates that are not in the first set
Reproduction Steps
If you have something like this:
Expected behavior
Actual behavior
Regression?
No response
Known Workarounds
Configuration
.NET 6.0.101
Windows 11 21H2
x64
Other information
The code in Except.cs (line 94) uses a HashSet, thus eliminating the duplicates due to the comparer, which are not real duplicates
Associated WorkItem - 200997
The text was updated successfully, but these errors were encountered: