Change VecMap's iterators to use wrapper structs instead of typedefs.

[csouth3]

Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the iterators of VecMap to use
proper new types, rather than type aliases. However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

[csouth3]

If changes like this are desired for the other maps that use typedefs currently (like BTreeMap, TreeMap, and TrieMap), I'd be happy to do the same for those as well.

[oli-obk]

wouldn't a newtype be more correct here?
once trait forwarding lands this would result in less code-noise

[Gankra]

It's not clear that we'll be getting trait forwarding any time soon, if ever. As such this is perfectly fine.

[Gankra]

Would it be possible for these to implement DoubleEnded as well? The Vec iterator is ExactSize, so I believe it should be DoubleEnded for these adaptors. If not we should consider a set of adaptors that do permit DoubleEnded iteration.

[csouth3]

So after looking closer at iter::Map, it implements DoubleEndedIterator, ExactSizeIterator, and RandomAccessIterator, so I could definitely implement at least DoubleEndedIterator if not the other two as well for keys and values. Also, iter::FilterMap implements DoubleEndedIterator as well, so I could implement that for MoveItems as well.

[Gankra]

Also as a minor style point I tend to "squash" impl-forwarding methods like these to reduce the noise. That is:

impl<'a, V> Iterator<uint> for Keys<'a, V> {
     #[inline] fn next(&mut self) -> Option<uint> { self.iter.next() }
     #[inline] fn size_hint(&self) -> (uint, Option<uint>) { self.iter.size_hint() }
}

Because it's code that doesn't really "matter". Just trivial boiler-plate.

This is a personal thing though, so I won't block this on it. No real convention. See e.g. btreemap for an actual example of this in our codebase, though.

[Gankra]

I'd also prefer that we don't #[inline] these. Want to start cracking down on blind inlining.

[csouth3]

I'm in the process of adding DoubleEnded etc anyway, so I'll just squash these down while I'm in here!

[csouth3]

@gankro Documentation is fixed.

[tbu-]

@csouth3 Answering your question, this would be nice for all collections, including BTreeMap, etc.

[csouth3]

@gankro Got wrecked by the closure unboxing pull that just got merged, hah.
I've now rebased.

[csouth3]

@gankro Is there anything I need to do to get this moved out of "BAD"? This took the fall for the auto rollup but it wasn't the offending PR.

[tbu-]

@csouth3 Ping @gankro, like you did.

[Gankra]

Sorry, saw this on my phone and promptly forgot about it 😅

[csouth3]

Brought down by the cruel auto-rollup again :^)