Confusing type-deduction of integer literals in generic contexts

[gnzlbg]

The way in which the types of integer literals are deduced in generic contexts is confusing. For example, the following:

trait Int {}
impl Int for i16 {}
impl Int for i32 {}
trait UInt {}
impl UInt for u16 {}
impl UInt for u32 {}

fn foo<T: Int>(x: T) { println!("size: {}", std::mem::size_of::<T>()); }
fn bar<T: UInt>(x: T) { println!("size: {}", std::mem::size_of::<T>()); }

fn main() {
  foo(10);
  bar(10);
}

works for foo but fails for bar. Weirder is that uncommenting the impl UInt for u16 {} makes it work.

IMO both cases should either work or fail (I would prefer work).

The error messages is:

error[E0277]: the trait bound `i32: UInt` is not satisfied
  --> <anon>:13:3
   |
13 |   bar(10);
   |   ^^^ the trait `UInt` is not implemented for `i32`
   |
   = note: required by `bar`

error: aborting due to previous error

I interpret from this that rustc is only trying with i32 (for whatever reason) even though the code does not contain any explicit mention of i32 anywhere. Still, removing one of the impls of UInt makes the program type-check, so rustc is able to deduce unsigned integer types in some situations.

EDIT: After going through the book without any luck, I found the following in the Rust language reference:

The type of an unsuffixed integer literal is determined by type inference:

- 1. If an integer type can be uniquely determined from the surrounding program context, the unsuffixed integer literal has that type.

- 2. If the program context under-constrains the type, it defaults to the signed 32-bit integer i32.

- 3. If the program context over-constrains the type, it is considered a static type error.

I guess that removing the impl UInt for u16 {} switches from rule 2 to rule 1, explaining the behavior.

[gnzlbg]

I prefer explicit over implicit, but the current situation is already doing a lot implicitly.

As a rule of thumb, if you are going to do something implicitly, you better make sure that it always works as the user expects. In this situation, this is sadly not the case.

Since we cannot make this explicit without breaking backwards compatibility, maybe doing a bit more work implicitly to improve the ergonomics is worth it.

The issue is with rule 2, which defaults to i32 when the type is under-constrained (that is, there are multiple alternatives). My example breaks because it provides an under-constrained context that does not accept i32. A backward compatible fix is to complicate rule 2 as follows:

• If the program context under-constrains the type, it defaults to the signed 32-bit integer (for backwards compatibility). In this case, if type-checking fails, all integer types are tried in the following order and the first type that type-checks is chosen: first all signed and afterwards all unsigned integers from narrower to wider.

I think it is backwards compatible because it only admits new programs that did not type-check before. It solves the situation since now both cases, Int and UInt, are handled identically and both type-check.

This fix relies on "try to type-check, and if that fails, then retry". I am not familiar enough with rust type system and the compiler internals to know how feasible this is, but I cannot think of an easier way to fix this preserving backwards compatibility.

[steveklabnik]

Triage: no change

[jonas-schievink]

Retagging as language feature request, but it seems likely that this would need an RFC

[Mark-Simulacrum]

I don't think the suggested change is very viable -- Niko has commented that extending fallback is in general quite hard, and this sounds like a very hard extension. I would definitely expect an RFC or similar to this, so closing.