Open conradludgate opened 3 years ago
Note that things like array_windows
for iterators are under discussion for iterators in std, see conversations like https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Iterator.3A.3A.7Bpairwise.2C.20windows.7D/near/224587771
As I understand it std
didn't want the tuple ones because of the extra trait complications in the interface, but with const generics available the array ones might be able to live there instead of here.
Could this be added and gated on rust 1.51? That'd maintain backwards compatibility without any problem
@Plecra We use 1.43.1 at the moment but will move to 1.51 at some point and use const generics, no doubt. I don't think there is a discussion about when we will do it but I suppose after #755 (well underway) and #844 (not started).
Now that #959 is merged, can we also start to merge other https://github.com/rust-itertools/itertools/labels/const-generics PRs? I really want to see array_windows
and many other possible array-based features which simplify my code.
Yes! I'm going to try to get some of these merged in the coming weeks.
Discussed in #546 where I've written an alternative to
tuple_combinations
,array_combinations
which is an iterator that outputs[T; N]
. This feature requires const generics which were introduced in Rust 1.51. It was suggested that we can bump the MSRV in a major release (ie itertools 0.11) but it would be sensible to add more features along side.This crate uses a lot of tuples where arrays make more sense. Tuples are good when you have multiple types (eg cartesian product or zip) but when you have a collection of the same type, a slice/vec/array makes more sense.
Here's a list of functions that seem to qualify using arrays:
These all work on a single iterator over the single
I::Item
type, and since these use tuples, the number of elements is known at compile time, making them perfect for using arrays instead of tuples.