About type inference coming to the C language as well

Posted Dec 11, 2023 3:08 UTC (Mon) by NYKevin (subscriber, #129325)
In reply to: About type inference coming to the C language as well by NYKevin
Parent article: Modern C for Fedora (and the world)

And, after posting this comment, I've realized that the reason into() doesn't work is because you're *supposed* to write this instead:

let z: i32 = x + i32::from(y);

Obviously I need to spend more time studying Rust, or maybe actually sit down and write a toy program in it.

Finally, I should note that you can write "y as i32", but that's less safe because it will silently do a narrowing conversion. from() and into() can only do conversions that never lose data, and there's also try_from()/try_into() if you want to handle overflow explicitly.

About type inference coming to the C language as well

Posted Dec 11, 2023 13:08 UTC (Mon) by gspr (guest, #91542) [Link] (1 responses)

> and there's also try_from()/try_into() if you want to handle overflow explicitly.

And there's try_from().expect("Conversion failure") for those cases where you wanna say "man, I don't really wanna think about this, and I'm sure the one type converts to the other without loss in all cases my program experiences – but if I did overlook something, then at least abort with an error message instead of introducing silent errors".

About type inference coming to the C language as well

Posted May 8, 2024 15:41 UTC (Wed) by adobriyan (subscriber, #30858) [Link]

Rust could allow "u32 = u32 + u8" with it's usual overflow checks, but not "u32 + i8".

The "messy numeric conversions" are largely due to rubber types and the fact that there are lots of them
(5 main, __uint128, size_t, uintptr_t, intmax_t, ptrdiff_t). POSIX doesn't help with off_t.

If all you have is what Rust has, C is not _that_ bad.

Kernel has certain number of min(x, 1UL) expression just because x is "unsigned long", but it is clear that programmer wants typeof(x).