-
Notifications
You must be signed in to change notification settings - Fork 18k
sort: clarify Slice comparator requirements #73420
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
Comments
Related Issues Related Code Changes (Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
Change https://go.dev/cl/666355 mentions this issue: |
I'm not certain that changing the spec is the way forward here. I'd rather change the implementation so that it conforms to the spec as written. |
@randall77 think of this as a clarification and not a change to the doc. the doc is written poorly. practically speaking, everyone assumed strict weak ordering. but it was written in a way that, I'd argue, gave weaker requirements than is necessary. I've changed the title |
Should we just require a strict weak ordering everywhere then? |
Yes, I've changed it. we already require a strict weak ordering everywhere, this just clarifies that. As for the difference in sort vs stable, I've dropped that. There is a different in the requirements only from the implementation, but not the doc. I'd prefer it to be part of the doc / spec as well, but that would require more work in justifying. And, I see that C++ stdlib doesn't provide a public distinction either, so it's probably best to just stay consistent anyway. |
The doc for
sort.Slice
states:This is referring to the less function interface here:
This describes only transitive ordering. In contrast, the underlying algorithm, pdqsort, requires strict weak ordering.
This is an important distinction. If a comparator is, for example:
Then it will be conforming to the documented requirements yet will still cause crashes under nebulous implementation defined circumstances. e.g. the number of elements to sort is greater than 33, and elements happen to be in a specific order.
To fix:
Change the documented requirement of
sort.Slice
to what is stated insort.SortFunc
.The text was updated successfully, but these errors were encountered: