N as T should interpret N as i32 if N is a literal

[mahkoh]

If N is a literal then it's impossible for the compiler to infer a type for N because it will be cast to another type right away. Therefore it has to use the fallback which is i32. At the moment it infers T as the type of N.

[Kimundi]

I agree that it does not make much sense, but this is intentional behavior and thus this issue should probably go in the RFC repo.

[huonw]

Does this cause problems in practice? Is it even observable other than via compiler lints about out-of-range literals?

[Kimundi]

I don't think it causes problems directly, but the mere fact that it is yet another weird special case is reason enough to not support it, imo.

Especially because there is a more idiomatic way already: Type suffixed integer literals. Why have a special way to write 100u8 as 100 as u8 that is inconsistent with how the as operator works everywhere else? Plus, 100: u8 will probably become possible as well in the future, which would have the same meaning as the current special case.

[pnkfelix]

Note that there are definitely problem associated with this oddity in the const-evaluator, see for example #23833