Change:
Currently uses for counting. This is necessary when iterating over slices (probably the most common scenario). However, in general an iterator is not necessarily related to memory, so it may make more sense to use other integer types. It seems sensible to make generic over the integer type used for counting. This is backwards compatible, so it shouldn't break existing code. Would it be possible to make this change although is marked as stable?
nominating, like we've been doing for possible backompat-libs issue
Isn't it likely to break code where the integer type can't be inferred?
A little off-topic, but doesn't now do the exact same thing as ? We can just zip with to do with . =
Python has both of them as well, I think it is common enough to warrant its own iterator. On Tue, Feb 24, 2015, 09:30 Utkarsh Kukreti wrote:
E-needs-decision. cc 1.0 beta P-backcompat-libs.
Personally I'm inclined to keep things simple and just use here. In particular, to do otherwise would require basically adding an associated type to the trait, because we must have some way for generic wrappers like to reflect the index type of the things they are iterating over.
(The fact that zipping with provides an easy way to use other kinds of integers if you prefer is nice, though.)
Then I would honestly rather remove than having a crippled version.
itertools already has a generic (which is basically the same as zipping with ), you could possibly import that into libcore. Specifying the starting point adds another degree of customization and an obvious place to specify the integer type. For a generic I would worry it's too confusing and nonobvious how to specify the integer type to use. Standard .enumerate() is not crippled just because it's simple. It's one of a million possible iterator adaptors, and not all of them are going to be included in Rust by default.
I personally see as a common iterator adaptor which is expected in a library of iterators, so I would not want to remove it in favor of the less intuitive . I think it's fine to have the open ended range to count with an arbitrary integer, but I don't think we need to change as-is.
Well, then let's at least mention in 's documentation as the more flexible variant. On Thu, Mar 19, 2015, 04:03 Alex Crichton wrote:
Ok after some more discussion the conclusion is that we probably don't want to make generic over integer types due to worries about inference and overcomplexity. This does seems like a worthwhile A-docs bug though, so I'm going to apply that label to ensure that we mention the alternative in the docs.
triage: P-high ()

Discussion:
/// assert_eq!(it.next().unwrap(), (&0, &1)); /// assert!(it.next().is_none()); /// ``` <ins> /// /// `zip` can provide similar functionality to `enumerate`: /// /// ``` /// for pair in "foo".chars().enumerate() { ///     println!("{:?}", pair); /// } /// /// for pair in (0..).zip("foo".chars()) { ///     println!("{:?}", pair); /// } /// ``` /// /// both produce the same output. </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")] fn zip<U: Iterator>(self, other: U) -> Zip<Self, U> {

/// Creates an iterator that yields a pair of the value returned by this /// iterator plus the current index of iteration. /// <ins> /// `enumerate` keeps its count as a `usize`. If you want to count by a /// different sized integer, the `zip` function provides similar functionality. /// </ins> /// # Examples /// /// ```