Sort colors in .Filter in a stable way, even with duplicate names #25
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Maybe fixes #24
My idea is to add a deterministic sort by the color if the names are the same.
On my first tests it seems that
is enough to make it stable,
However maybe it is even more guaranteed if I use
.SliceStable
instead. So I used that.I tried to write a test for this, but it is quite hard to reproduce this error in a test, because when I create a simple loop calling the filter multiple times, I always get the same result for each round.
However when writing a simple program logging the output and executing this several times I get always different outputs. (50/50)
With the new code I always get the same output.
But for that its harder to write in a test.
And furthermore I noticed a very interesting / strange behavior with Go while I tried to write a test:
When I run the old code with this it fails. because the expected order is always the wrong way around.
Even when I switch the expected order it still fails. Because of some weird optimization, the actual order is exactly the opposite now^^
But I am not sure if that is reproducible on your end, because it also may have something to do with how the CPU execution branches work, Go compiler optimization or smth. like that? ...
However with the new code it always succeeds.