[Pre-RFC] Implicit number type widening

[scottmcm]

Unfortunately, the examples that have come up in the thread are making me less confident than I originally was that I'd like widening coercions in Rust.

I think that, overall, the scenarios that have come up make me want to see how well they can be done with more trait implementations before contemplating adding coercions.

@djc

Comparison

When numbers of different types are compared, coerce the smaller type to the larger to enable the comparison.

Note that the cases where that works aren't the ones that I find interesting, because from works decently. There isn't a "larger" type when comparing i128 to u128, though, so I strongly think additional trait impls are a better way to make comparisons work than coercions would be.

@djc

Indexing

Allow indexing with different unsigned number types. The trick here is to make sure we don’t unduly affect portability, since the “native” index usize type could be any of u16 , u32 or u64 in practice. The question is how much that matters since the collection length is the more important constraint here, and will often be more limiting than the platform’s size type length.

I think this is again better done with additional impls than with coercions, especially looking at the portability point. a[i] always has the possibility of panicking, so if additional impls mean that that ends up really just being a[usize::try_from(i).unwrap()], I'd have no problem with that. (Continuing the "if the right way is longer than as, just do it automatically" idea.)

---

@Dushistov

And again what if it is program bug, and a may be variable “a” should be i16 ?

Can you show an example where it's a bug and it's only used in the comparison? (The bit representation is pretty irrelevant for such a comparison, because LLVM will probably have sign-extended them both into i32 registers anyway.)

@Dushistov

and user don’t want indexing with u8

Two things on this:

1. I feel like they usually will fix such an error today by a[i.into()] or a[i as usize] --- not by changing the type of a variable that they clearly wanted to be something badly enough to annotate it --- and thus they have the same problem anyway

2. I would expect literal comparisons like that to get the same "warning: comparison is useless due to type limits" that you get today with things like i <= 255, so having the mixed mode could actually be better for finding errors, since today the way to "just work stupid compiler" is (i as u16) < 256_u16, which doesn't give warnings.