Are casts encouraged in Rust?

Posted Jun 29, 2025 20:29 UTC (Sun) by epilys (subscriber, #153643)
In reply to: Are casts encouraged in Rust? by alx.manpages
Parent article: How to write Rust in the kernel: part 2

They make sense in a lot of usecases, plus they are opt-in/explicit, so they are neither encouraged or discouraged in my (humble) opinion. If you make a mistake with casts, it's basically yet another logic bug.

The good news is that if you wish to not allow them in your codebase, you can use lints like `clippy::as_conversions` and deny them globally: https://rust-lang.github.io/rust-clippy/master/#as_conversions

Are casts encouraged in Rust?

Posted Jul 2, 2025 17:09 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

... Or even filter out which "as" conversions you want to allow and which you want to deny.

Are casts encouraged in Rust?

Posted Jul 2, 2025 20:32 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (1 responses)

But if there's no other way than using a cast (in constant expressions), we have a problem.

Casts are a known problem

Posted Jul 3, 2025 11:54 UTC (Thu) by farnz (subscriber, #17727) [Link]

Casts are a known problem, and (AIUI) people are working to make the "as conversions" clippy lint a warn-by-default lint. There's some issues to resolve before we get there:

To do a good job, we need a way to say "you can implement a trait with either const fn or fn, and if you use const fn, we can use this in a const context". We can't, however, say that all conversions happen in a const context, partly for backwards compatibility, and partly because we still want to support conversions that can't be done in a const context. But this would let us support let x: u16 = y.into(); type of safe conversion, or const z: u16 = y.try_into().unwrap_or_else(0);.
There needs to be a carefully considered plan for handling fallible conversions sensibly, and allowing you to choose behaviours. For example, converting u32::MAX to f32 could be a bug, and a reason for a good compile-time error (because f32 has 24 bits of precision, while u32 has 32), or you could want to round down to the first f32 below u32::MAX, or even round up to the next f32 above u32::MAX.
You don't want to make the obviously correct code unclear or hard to write. If a conversion is, in general, fallible, but in this specific instance is known to be infallible, I should be able to use an infallible conversion operator. For example, const MAX_SIZE: usize = 0xfe; const ERROR_INDICATOR: u8 = MAX_SIZE.into(); should work, since it's obviously possible to convert 0xfe to a u8, and you don't want to force people to write const ERROR_INDICATOR: u8 = MAX_SIZE.try_into().expect("Too big for u8"); when it's obviously infallible in context.

There's thus a lot of design work in getting this right; it's OK if the initial solution only solves for some of these problems, as long as it doesn't block off useful bits of the design space for other solutions. I'd thus expect that we'll have a decent solution to the first problem - traits usable in const and non-const contexts if they implement a function as const fn, but only in non-const contexts if they implement it as fn - long before the other 2 get solved, because it's the lynchpin on which the other two stand - and indeed, work on this is actively happening, leading to an early design that's being pushed around until people are confident that it's a good design.