Implicit Numerical conversions only when data is not lost
Auto cast up numerical types for example: int8 + int32 becomes int32 + int32. The idea comes from @haxiomic who also notes "The compiler will error if you try to do an lossy operation"
This should be much nicer when working with the stdgo numerical types on the Haxe side.
The accuracy required also depends on where the result of the calculation is being put.
For example if the result of int8 + int32 is to be stored in an int64, then the whole calculation needs to take place using int64. If int32 were to be used, the result would be inaccurate when sum of the two values overflowed the int32 range.
Wouldn't that make it impossible then to have a smaller number overflow in a bigger number because the compiler would look through all of the chains of assignment and make very large numbers (or I guess you could have the compiler only look as far as a single assignment)? It seems to me that int64 = int8 + int32 -> int64 = int32 + int32 makes more sense then int64 = int64 + int64 conversion because the binary operator acts on the value and the type, where as an assignment acts on the value and type too but only after the binary. This is probably why Go makes it so all number conversions need to be explicit 😅
Yes, you are right @PXshadow, this is why Go always requires explicit type conversions.
Not feasible at the moment and a small QOL feature not an issue to worry about at the moment.