Possibly change the ordering of integer-literal inference and method selection.

[sanxiyn]

fn sub(i: int) { for i.times {} }
fn main() {}

test.rs:1:17: 1:31 error: type `int` does not implement any method in scope named `times`
test.rs:1 fn sub(i: int) { for i.times {} }
                           ^~~~~~~~~~~~~~
error: aborting due to previous error

This works in master(2372d2c) but is broken in incoming(42b462e).

[Kimundi]

It's not broken, the devs just changed it yesterday. ;) times now only is defined on uint

fn sub(i: int) { for (i as uint).times {} }
fn main() {}

should work.

[graydon]

Yeah, there was a .. very unfortunate interaction between integer-literal type inference and method selection that meant we wound up accidentally calling one of the numerous integer-typed overloads of .times chosen more or less at random when someone writes 1000.times { ... }, is is common with this method. There's not enough type information in the environment to pick a specific variant. So we removed the source of non-determinism in this selection and the result was that all such calls were ambiguous, so we further removed all variants aside from the uint one.

We realize this is a bit awkward but it seemed the lesser evil of all the options available at the time of writing. A more complete variant might interleave integer-literal type inference and method selection, but we did not have confidence in our ability to produce such a variant in a timely or correct manner.

I'll rename this bug as a placeholder for figuring out something more clever to do here instead.

[emberian]

Not an issues now that there is an ambiguous method checker thing, I think?

Example:

foo.rs:3:12: 3:23 error: multiple applicable methods in scope
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #1 is `std::int::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #2 is `std::i8::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #3 is `std::i16::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #4 is `std::i32::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #5 is `std::i64::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #6 is `std::uint::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #7 is `std::u8::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #8 is `std::u16::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #9 is `std::u32::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~
foo.rs:3:12: 3:23 note: candidate #10 is `std::u64::generated::__extensions__::to_str`
foo.rs:3     println(x.to_str());
                     ^~~~~~~~~~~

Can you confirm, @graydon>

[huonw]

Triage visit; as @cmr points out, this is now an entirely different error, but it's still fairly strange since a literal 1 defaults to int, but 1.to_str() doesn't default at all (it's hard to balance the unfortunate magical defaulting vs usability):

fn main() {
    1.to_str();
}

4704.rs:2:4: 2:15 error: multiple applicable methods in scope
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #1 is `std::int::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #2 is `std::i8::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #3 is `std::i16::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #4 is `std::i32::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #5 is `std::i64::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #6 is `std::uint::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #7 is `std::u8::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #8 is `std::u16::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #9 is `std::u32::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
4704.rs:2:4: 2:15 note: candidate #10 is `std::u64::generated::__extensions__::to_str`
4704.rs:2     1.to_str();
              ^~~~~~~~~~~
error: aborting due to previous error

[steveklabnik]

Now that fallback is gone, is this still relevant?

[nikomatsakis]

Fallback is back, but it happens late in the cycle, and hence you still need explicit annotation if you plan on invoking methods. This is how the RFC was written and it was no accident, I think we have no plans to change this. Closing bug.