Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Make sure the type inference for the new range expression work as // good as the old one. Check out issue #21672, #21595 and #21649 for // more details. fn main() { let xs = (0..8).map(|i| i == 1u64).collect::<Vec<_>>(); assert_eq!(xs[1], true); let xs = (0..8).map(|i| 1u64 == i).collect::<Vec<_>>(); assert_eq!(xs[1], true); let xs: Vec<u8> = (0..10).collect(); assert_eq!(xs.len(), 10); for x in 0..10 { x % 2; } for x in 0..100 { x as f32; } let array = [true, false]; for i in 0..1 { array[i]; } } </ins>

Related discussion:
text: cc
I think you have a PR that improves type inference in some cases where closures are involved (?), do you know if by chance that fixes this as well?
This is not closure specific:
This must be duo to . It seems to enforce the numeric fallback rule a bit too eagerly.
Another example from IRC is that type checked while didn't. Rather interesting.
edwardw, not just that, type inference regressed slightly at the time of the range stabilization PR.
also related
Have a partial fix by deferring numeric fallback, but it seems to hit now.
OK, so I spent some time digging into this. I don't think that deferring numeric fallback is necessarily the solution. sorry if I kept disappearing on IRC, I had to put my head down and study the log to see what was happening. So what seems to happen is that we correctly come up with the constraint: However, we are unable to make the connection between and . The reason is that the new has separate impls for each of the numeric types, whereas the old had only impl for a type . When we process the projections, we first try to resolve (without considering the output type ), and we get ambiguity, because there are many impls that could apply. Unfortunately this all seems a bit right to me. Basically we're trying to infer the type of the range from the output type, which is the reverse direction inference is supposed to go. When we used a blanket impl, we were able to resolve this because there was only one impl for . Probably the best fix is to go back to that, actually, but this is an interesting quandry. I'll have to think about it a bit.
To be clear, the example I was digging into was
Also, to put it another way: having a single blanket impl allows us to draw the connection that when you iterate over , you get . With the current setup of many distinct impls, that is not known to be true.
After some discussion with on RFC, I just wanted to clarify a few things (I myself was a touch confused too). the impl is probably the easiest way to fix this in the short term. , to some extent, this limitation is an artifact of how trait matching is implemented. That is, we intentionally do not take output bindings into account when selecting traits.