I was thinking about eliminating @floatFromInt and allowing automatic coercion of integers to floats, while still requiring @intFromFloat to go the other way. This would also apply when mixing float and int operations (resulting in floating point values).
Rationale here is that pretty much all floating point operations are understood to round, so an explicit cast is redundant.
On the other hand, there’s an argument to be made against this. While it does not require a cast to coerce a f32 to f64, going the other way does require a @floatCast, because it can result in loss of precision. That is precisely what is also happening when coercing an integer to a float. So it’s pretty hard to justify one of those without the other.
Maybe it could work with integers with small enough bit sizes. For instance, f64 supports the entire integer range of i32 (and u32), so it seems reasonable to support implicit coercion of i32 to f64 - no information can be lost. For 32 bit floats that would allow operating on integers up to 24 bits - pretty reasonable if you’re in pixel space.
It’s not the whole story, but I think that could go a long way towards making game logic code less tedious without compromising the “no information lost by accident” design goal of the numeric type system.