there's some constants in the standard library that use kinda odd types, like usize::BITS being a u32.
there's been some talk about edition-dependant names, but what about edition dependant types? this would further increase the types of changes rust can make.
this could be implemented with edition-dependant aliases, eg. having usize::BITS resolve to usize::BITS_U32 or usize::BITS_U16.
this could be done at the ast desugaring level, making it so most of the compiler doesn't need to worry about it.
Why should usize::BITS be u16 specifically?
Personally I think usize::BITS should be usize, and u16::BITS should be u16.
I’m pretty sure that if you do a code search for BITS, the most common use case by far is in the rhs of a shift. So it makes the most sense that the constants have the type that shifts expect.
u32 and i32 are the most reasonable candidates for "standard integer types", and using them when there’s no reason to use anything else is consistent with other languages where they’re spelled just "int". In fact they were once named uint and int in Rust, too!
I'm pretty sure that BITS isn't changing from u32, because that's what everything is using for that right now. unbounded_shl takes u32, count_ones returns u32, ilog2 returns u32, etc.
And of course returning u128 from u128::count_ones is not an improvement.
(But with luck we'll find a way with pattern types to have u16::count_zeros return u32 is 0..=16, which is more accurate than any specific integer type, even if we had u<5>.)
I'm a little annoyed that num-bigint has to be different and use u64 for all those though -- even a 32-bit target can have more than u32::MAX bits, however impractical that may be. (and yes, 64-bit targets could theoretically have more than u64::MAX bits, but that's easier to dismiss...)