I would expect them to use `u32` or `u64`, since they aren’t necessarily tied to a datastructure of `usize` elements (like `Vec`). Should I file an issue?
Some examples:
```rust
fn size_hint(&self) -> (usize, Option) { ... }
fn nth(&mut self, n: usize) -> Option { ... }
fn skip(self, n: usize) -> Skip { ... }
fn take(self, n: usize) -> Take { ... }
fn position
You’d have to file it in the RFC repo, since it’s a major API change – and we’re past the beta, so it really has to be an emergency to go through 😄
I’ll explain why it’s not a very big deal.
The core API is this:
`fn next(&mut self) -> Option`
It has no assumption about length and can deliver elements infinitely. So infinite or longer than current `usize::MAX` iterators are supported.
`size_hint` has one primary purpose: to size allocations well when creating collections from iterators. In general, these are limited by `usize` too, so the types match well. Of course it does not match with sizing other kinds of resources, for example files. Fortunately it’s just a hint. The protocol specifies you should use `usize::MAX` as the bound if it is known to be larger than usize (including infinite).
The other methods, `nth`, `skip`, `take`, `position` are all un/fortunately **O(index)** complexity methods, which means that in practice you really want to avoid using big numbers here. Position is frequently useful with vecs/slices, which use usize indices.
I can see that it looks limiting… In the worst case though, they are just adaptors and library code can create their own, maybe there is a use case for `.take64(n: u64)` or even bigger!
---
It’s basically completely arbitrary, but it does serve a few use cases, where it’s referencing a container that contains a non-zero-sized structure that lives in the RAM.
---
Iterators aren’t backed by a specific data structure, but they certainly can by implemented by specific data structures. Those data structures might require usize.
---
But you can as well say: Iterators aren’t backed by specific data structures, but they can be implemented by data structures that require {`u32`, `u64`, etc.}.
---
It occurred to me that the nth, skip, take adaptors are overridable now again. I still think that doesn’t make them very viable for random access since the structs they must return are fixed. Maybe a future mature random access api can be formed and the question of type for the offsets will come up again.
---