Vic
Vic
I changed: - the bound on `L` from `QueryData` to `ReadOnlyQueryData` - removed `filter` from `QuerySortedIter` iteration, which made the internal `fetch_next` infallible. - added a test that checks whether...
(forgot cargo fmt)
`#[allow(clippy::unnecessary_sort_by)]` on the new test
I'm really proud of it! As soon as it clicked how satisfying this extension would be, I just had to implement it. And it'll become even cleaner with future Rust...
Are these not orthogonal concerns? I agree that table sorts will be very useful, and they can be used to early out of these sort calls, but I do not...
I do agree that it doesn't fully address the concerns of commenters under the issue #1470. Should this issue remain, or a new one be opened?
The problem with sort methods on anything other than the query iterators is that they would explode in API surface. - There are 6 standard sort kinds. - AFAIK being...
> > The problem with sort methods on anything other than the query iterators is that they would explode in API surface > Isn't the opposite the case? You need...
To be clear, the different suggested scopes for sorts: - global: a table sort - system-level: a `QueryState` cached sort - local to call: a query iterator sort
> > Your description would also require regressing unsorted iteration, which is a much larger use case > > It is precisely because unsorted is disproportionately more common that this...