There is an issue on rusts github about collecting iterators into arrays. The scenario mostly focused on in that issue is turning arbitrary iterators of, at compile time, unknown length into arrays.
However it turns out that quite a large subset of iterators and their methods affect the length in a way that would be possible to track in the type system. Some examples of methods on
Iterator that affect the length in a predictable way:
These iterators should then be possible to safely collect into an array without any unnecessary runtime checks.
I have started working on a proof of concept crate
iter_fixed that implements this (using several nightly features, mostly related to
It is work in progress but I thought I would kindly ask about your thoughts
This is my very first project that might potentially be used by others. Also, I am not too comfortable with very generic(that's the word?) code and weird trait bounds
- Do you think something like this would be useful to you?
- Anything related to license, MIT Apache is the preferred for rust right? (I have no opinion on the matter)
- Should the version in Cargo.toml start even lower like 0.0.x or is 0.1.0 fine this early on?
- Is there anything else that is wrong or could be improved with the project
- When does it make most sense to publish to crates.io? Anything to think about other than Publishing on crates.io?
- Code (The code is currently not much more than a const generic wrapper struct wrapping an ordinary
Iteratoronly exposing some of its methods to the public)
- Does the architecture(?) make sense?
- Naming - Reason for the name
mut_iter. Does this make sense or do you have other suggestions(both for crate/repo and types and functions)
- Do you have any generics related suggestions?
- Should I switch out Iterator[Fixed] with IntoIterator[Fixed] anywhere?
- Other things
- Should I try to hide the exact return types? How do I do that?(If I remember correctly
fn zip(..)-> IteratorFixed<impl Iterator<..>>did not compile)
- Anything else I can improve?