Should lossy conversions be compiler warning

[elichai]

Hi,
Should lossy conversions (i.e. let a = 300u16 as u8) be a compile time warning?
that way people can opt in with #![deny(cast_lossy)]

Otherwise maybe a way to make generic that have size constraints?

I'm working on a new library where I'm casting a bunch of stuff to usize and for example usize::from(0u32) isn't a thing. even though it should work on both 32bit and 64bit machines.

So right now I have a bunch of static asserts to check that size_of<usize> => size_of<u32>().

Edit: Related to #2715

[sfackler]

That would break backwards compatibility.

[elichai]

I know. :\

[sfackler]

It sounds like the answer to the question is no then, right?

[elichai]

I still think it's worth discussing it. maybe there are ways to do something similar without doing a breaking change (like generic constraints on the from function)

[elichai]

Maybe a compile time warning at least. (the compiler can easily check the sizes of the actual types in compile time, even if it's platform dependent)

Edit: that's actually interesting IMHO. that way it can be an error opt-in with #[deny(cast_lossy)]

[elichai]

I edited the original post

[sinkuu]

Is this clippy lint what you want? https://rust-lang.github.io/rust-clippy/master/#cast_possible_truncation

[elichai]

A. it doesn't seem to work with all primitives: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4408dede32fead57acb6c9d3f0192073.
B. I want it part of the compiler so I can make sure my code will never compile(or produce a warning in the softer case) in machines where the conversion is lossy (i.e. especially when casting usize or raw pointers where the sizes are different per machine)

[SimonSapin]

My preferred approach would be to add APIs for all remaining combinations of types that as supports but do not have a corresponding API yet (similar to From impls for lossless integer conversions), then deprecate as entirely. (Possibly in a future language edition.)

However there is a lot of design work needed to get those APIs right.

[scottmcm]

While I always support moving people away from as, there needs to be a way to do these things that's not #[allow].

If anyone wishes to make progress on this, I suggest trying to unblock (at least parts of) #2484