By the way, I always wonder: is there a reason for no Iterable trait, which for could just take directly and implicitly call `.iter()` on? E.g. why
for e in my_vec.iter() {
for e in my_vec {
?Iterator implements Iterable as a trivial self-return (by default), and `for` only and always takes an Iterable?
> what if you implement both?
Depends what sort of weirdness you're trying to do I guess.
> I believe it didn't work with the trait matching rules.
Ah. Too bad.
One of the reasons why the C++ for (:) syntax above feels like such an improvement over the traditional iterator for loop is that it cuts out a lot of noise that's the same for almost every container loop you ever do. The same objection could be raised as in another branch of this conversation, that you might have other kinds of ranges on an object, and I've even done that before (as obj.something_begin() and obj.something_end()). But even before ranged-for came it almost always turned out ugly and I regretted it.
If most uses of for in Rust call iter() (I don't know that they do, my experience with it thus far is really minimal, but it does seem common so far), it seems like a case where use should lead design and the extra noise cut out.
Basically, if I have more than one kind of range on an object I'd probably rather have functions on the object that return the 'unusual' ranges for the iteration. So rather than having:
for i in obj.iter() # the normal thing that I use all the time
for i in obj.bfs_iter() # something I use sometimes to be more explicit
for i in obj.dfs_iter() # another thing I use sometimes
for i in obj # the normal thing that I use all the time
for i in obj.breadth_first() # something I use sometimes to be more explicit
for i in obj.depth_first() # another thing I use sometimes
It seems entirely sensible to me to expect the for loop construct to take an Iterable object. It actually makes more sense to me than for it to take an iterator directly, conceptually.
On the question of 'what if both?' I'd propose making it so hard (or impossible?) to do that. If for took Iterable, and Iterators also implemented Iterable as "return this", there'd really be no concept of having both (except in that if you have an iterator, it is always both) and for itself would be left fairly uncomplicated while still being able to take both Iterable and Iterator objects.
I'm probably missing some reason why this isn't an obvious way to go, as a definite Rust newb, but it would feel natural to (my C++-rotted perhaps) brain. Also I know there's no language changes until post-1.0, so for now it is what it is.
[edit] Huh. Ok, re-reading it looks like this was almost all covered ground. Never mind.