Multiplication of Int64 and Int32 may result in Int32 (risking overflows at runtime) about crystal HOT 4 OPEN

Yeah, this behaviour is expected and (currently) intended. I agree that it can be confusing, though.

The underlying idea is that performing an operation on a variable should not change the type of the variable. This is particularly relevant for the assignment operators, such as a *= b (which is equivalent to a = a * b). It would be weird if the type of a was changed by this operation.
So the math operators ensure that typeof(a * b) is always equal to typeof(a).

Knowing this practical reason, I believe the behaviour is quite comprehensible. But it's not without alternatives.
It's just that this solution was chosen for Crystal and we have to live with it.

I think this could potentially be changed in the future. I would support that because it's an odd rule and confusing.
But I'm not sure how much effort it would be. However, I'm confident that we can find an alternative that is more approachable and less surprising, and probably won't break too much of existing code. It would still be a breaking change, though. So it's not an immediate concern.

from crystal.

It goes further than just the assignment operators. See #8111 and #8872.

IMO integers are broken in Crystal, or at least not as simple as they could have been; either you live with the default Int32 everywhere or you type everything when you need explicit sizes, down to each literal value 🤷

I wish this had been fixed before 1.0 but we instead kept the rule that the left-most type is the result type, so Int64 * Int32 returns an Int64 while Int32 * Int64 returns an Int32, which means that you should always write a * 1 instead of 1 * a so you can keep the type of a... unless you want the result to be an Int32...

from crystal.

Maybe a *= b should be made equivalent to a = a.class.new(a*b)? This would work with unions but maybe has runtime overhead (it can be optimized to old behavior when typeof(a*b) == typeof(a))

from crystal.

Yeah, that could be an option.

I'd like to look into requiring identical number types for math operations. Thus you would need to be explicit about type casting when the types don't match. Auto-casting should cover some basic use cases, so it wouldn't be too much noise.

from crystal.