dont handle bool transmute by bend-n · Pull Request #140431 · rust-lang/rust (original) (raw)

as the suggested change produces something with identical semantics and no possibility of UB on misuse

Identical observable semantics, yes, but potentially very different performance behaviour.

I'm strongly in favour of rustc saying "use this non-unsafe thing when there's literally no downside to it", like char→u32 there's no reason to use transmute because as is exactly the same codegen. It's always (outside a macro) wrong to use transmute there.

But for u8→bool, it's not necessarily wrong. And if this is something that someone's doing intentionally -- maybe they needed to pass their bool through a C char -- then no they don't want the != 0 version necessarily. So then this lint ends up saying "you should write { assert_unchecked!(x <= 1); x != 0 } instead of transmute::<u8, bool>(x)", and it's not clear at all to me that that's good advice. I might actually say that the transmute there is better.

That means to me it's a "which is the recommended way to write it, even though both are in a sense fine" lint, which is more clippy's domain than rustc's. If the only way to avoid the lint is to allow it, and reasonable code might want to do that, then I think it's a bad lint for rustc.

TL/DR:

• I think the place for the "you should use x != 0" is the existing hint for trying to use x as bool, not here.
• This transmute is actually quite useful, because getting a bunch of extra icmps in the codegen can be problematic.