This arose in the discussion about indexing with non-
usize integer types; splitting this into a separate topic.
I'm a lot less uncomfortable with the idea of mixing sizes; that seems unlikely to do the wrong thing, generally.
My strongest feeling there has been that writing the correct-numerically version of the [ed: mixed-signedness] comparison is incredibly annoying, so the usual result of the error is doing it wrong by
as-casting one side.
my_u8 < 300 is currently a deny-lint because it causes wrapping, not a type error; I think it being a "that's silly" warning-lint (like
my_u8 >= 0 already is) would be an improvement.
u64 doesn't seem unreasonable to me. That's going to give a sensible answer even if the u64 is out of range (false).
Unfortunately mixing sizes without mixing signedness is the same inference-breaking problem as allowing only unsigned for indexing
My concern lies primarily with signed types, where sometimes you might want the numeric answer, and sometimes you're just dealing with an interface that's sloppy about signed vs unsigned and you actually want
some_i32 as u32 == some_u32.
(meaning, turn negative values into the equivalent twos-complement positive)
Hmm, good example.
That's pretty much the example for me, that makes me want Rust's careful help to think about which behavior I want any time I accidentally mix the two.
(I'm coming from a world where
-1 is considered a perfectly reasonable way to spell
Oh, that reminds me...
>/etc stay as operators down to MIR, right? So if we needed an inference hack it could plausibly be syntax-restricted?
IMO, we should add a library function for this first.
And see how often it's used and in what circumstances.
The lack of implicit cross-type operations is an important feature, used for nudging user into the direction of using a coherent set of types in APIs instead of randomly piling up
longs and whatever like it's usually happens in C/C++.
@Vadim Petrochenkov I agree, and I think there's a balance here between "help the user correctly compare different types" and "help the user not mix types".
Sadly, when working closely to ffi the fact that the C programmers didn't care about their types and that Rust cares "too much" makes it needlessly painful.
However, I would say that the pain is less around
>/indexing specifically, and more around constants, which can't be simply declared to have "an integer type".
If you could declare that a const is just an integer and Rust would fill in usages of it as whatever size integer is needed then that'd solve a lot of the trouble. (As long as the literal wouldn't overflow, eg no 0xABCD as an automatic u8, but it could be a u16, i32, u32, etc).
The other const generics: generic consts.
It does sound silly, but for example the GL spec is written with the "wrong" signed/unsigned tags on a few of the functions, and C doesn't care, but it makes Rust folks grumpy. They file bugs against the GL bindings people, who ask the GL bindings generators people what's up, who tell them "yeah the spec is really written that way".