Redesign Int32 operator overloads with scalable type-parameter bounds; add compare()

[Copilot]

Int32 previously had ~40 @:op methods — many body-less (delegating to the underlying Int), and many exhaustively listing every type permutation (Int32×Int, Int×Int32, Int32×Float, Float×Int32, etc.). This approach does not scale: adding future types like Int8/Int16 would require updating every integer abstract with new overloads.

Changes

• haxe/Int32.hx: Redesigned operator overloads using the scalable pattern already present in non-Flash UInt.hx:

  • Arithmetic (+, -, *, %): only Int32×Int32; the from Int implicit conversion auto-promotes Int in both operand positions, so no separate addInt/intSub/etc. overloads are needed
  • Float arithmetic: removed entirely; @:to toFloat() auto-degrades Int32 to Float for Int32+Float and Float+Int32 cases
  • Equality (==, !=): @:commutative equalsInt<T:Int> + @:commutative equalsFloat<T:Float> — two overloads cover all integer and float types, and will automatically cover future Int8/Int16 types with to Int
  • Integer ordering (<, <=, >, >=): only Int32×Int32 via compare(); from Int handles mixed cases in both positions
  • Float ordering: ltFloat<T:Float> + floatLt<T:Float> pairs per operator (non-commutative, but <T:Float> bounds means Float32 etc. will work automatically)
  • Bitwise (&, |, ^): only Int32×Int32; from Int handles mixed
  • Shifts: single overload each with b:Int; Int32 shift amounts degrade via to Int

• haxe/numeric/Int32Native.hx / Int32Direct.hx: Added compare() (safe signed comparison via </>, not subtraction which overflows at boundaries) and mod().

Result

~50 overloads → ~35 overloads. Future integer types (Int8, Int16) with to Int will interoperate with Int32 operators automatically, with no changes needed to Int32.hx.

Operator design summary

Category	Overloads	Mechanism
Arithmetic (+,-,*,%)	1 per op	Int32×Int32; from Int auto-promotes
Division (/)	1	Int32×Int32 → Float explicit
Equality (==,!=)	2 per op	@:commutative <T:Int> + @:commutative <T:Float>
Ordering integers	1 per op	Int32×Int32 via compare(); from Int handles mixed
Ordering floats	2 per op	ltFloat<T:Float> + floatLt<T:Float>
Bitwise (&,|,^)	1 per op	Int32×Int32; from Int auto-promotes
Shifts	1 per op	Int32×Int; Int32 shift amount degrades via to Int

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Simn]

@copilot I'm looking at this thinking that it can't be the right approach to exhaustively list all allowed type permutations for all operators... this also isn't going to scale well if we add more integer types like Int16 and Int8 which are also assignable to Int, and thus can be compared to Int32. Could you check if there's a better design to handle this? I'm sure others have come up with a cleaner approach.

[Copilot]

@copilot I'm looking at this thinking that it can't be the right approach to exhaustively list all allowed type permutations for all operators... this also isn't going to scale well ...

The cleaner design is in commit 617efe6. The key mechanisms:

1. from Int auto-promotion eliminates all *Int mixed overloads — since Int32 has from Int, any Int value is auto-promoted in both operand positions. Int32 + Int, Int + Int32, Int32 & Int, Int32 << Int32 (shift amount), etc. all work via the single Int32×Int32 overload. This is the same pattern non-Flash UInt uses (it only has add(UInt,UInt), no addInt).

2. @:to toFloat() eliminates all Float arithmetic overloads — Int32 + Float and Float + Int32 both work automatically via the implicit @:to conversion. No explicit addFloat, subFloat, etc. needed.

3. <T:Int> and <T:Float> type-parameter bounds for equality — @:commutative equalsInt<T:Int> handles Int32 == Int AND Int == Int32 in one method. Crucially, when you later add Int8/Int16 with to Int, they'll work with Int32's equality automatically without any changes here.

4. Float comparison overloads use <T:Float> bounds — Still needs 2 overloads per operator (non-commutative), but <T:Float> means Float32 etc. will work automatically once introduced.

Result: ~50 overloads → 35 overloads. The pattern is now identical to UInt.hx (non-Flash), which has always used this scalable approach.

[Simn]

I'm concerned that this toFloat could cause unwanted floating point semantics to be silently introduced, but I can't find a case where that actually happens. The type parameter trick seems clever, but it's indeed always been there on UInt so I'm sure it's sound!