For example if I have foo as bar, and bar type is too small, the as will still proceed and cut bits off without a warning, which is likely to cause a bug at run time. OTOH foo.into() will not compile if bar type is too small.
Personally this doesn’t seem like a very significant pitfall to me.
I don’t see how it’s a problem for 32-bit targets. When usize is u32 it can be safely and losslessly converted to u64.
But it can’t be losslessly round-tripped. If I’m on a 32-bit target, and I do:
// on 32-bit target
let foo = std::usize::MAX;
let mut bar: u64 = foo.into(); // just sign-extended
bar += 10; // it's a u64 so this is fine
let baz: usize = bar.into(); // uh-oh, we just wrapped
At least to me it doesn’t make sense to provide
Into<u64> for usize but not
Into<usize> for u64, which would be needed if you want calls to
into() to be statically guaranteed as lossless.
However, you may be interested in turning clippy warnings on for this so that you will have to explicitly ignore cases where the behavior is intended: