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.
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
Support sorting iterators #46104
Support sorting iterators #46104
Changes from 8 commits
c762cbd
a00e018
d9316f8
54db6a6
b046e7a
8e94705
15b2a02
fe2ce55
e4cfffc
7c14f9d
36ff056
f32de07
1280aea
d9c8a7d
449f9ff
60e42f5
55d5e7e
f5ad11a
55c8efe
ac32a38
264836d
0c53911
9fc05de
6a838e5
d42c234
741017e
a0d3e4d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't infinite (and maybe unknown) also be errors? I see that people probably want an error for
sort(1)
, so ok, but kind of strange that that of all things would be disallowed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unknown sizes should be supported
For almost all infinite iterators, we already throw inside
copymutable
, but perhaps someone could define an infinite iterator that can becopymutable
ed, returning a sparse vector of infinite length. If they also define a sorting method for that sparse representation, then it would be a mistake to throw on infinite iterators.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But
sort
is an eager operation - surely if someone wants to sort their infinite iterator lazily, they have to implement it either way and not just rely on the generic fallback that's supposed to collect all elements of the iterator? Wouldn't it be better UX to throw early and make them aware where the actual problem lies, instead of having them chase down an (incidental) error fromcopymutable
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For generic iterables,
copymutable
collect
s, but it only needs to make a mutable copy, not necessarily instantiate every element. For example, I believe this is allowed:Nevertheless, we could put this in the same camp as
sort(::AbstractString)
: perhaps it might make sense in some way but for now just throw because it is rarely a good idea to sort an infinite iterable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Throwing on an infinite iterator seems like the sensible choice. I've made the change.