Integer data type

[flashultra]

Update The following changes are now suggested for this proposal:

• Replace Int64, UInt and UInt64 with native types (where possible) .
• Allows easy assignment for Int64, UInt and UInt64.
• Introduce new UInt64 type for all Haxe targets and use native where possible..

• Allows easy conversion between integer data types.

  Sometimes it is not so easy to work with Int64 types in Haxe. Recently anounced literal suffix and number separator make things better , but real support for Int64 ( replacing abstract class with the native for the target) will give better performace and will lead to more clean code. For example

  var v:Int64 = 9223372036854775807;

  and not var v:Int64 = Int64.make(0x7FFFFFFF,0xFFFFFFFF); Well with nigth build it could be var v:Int64 = 0x7FFFFFFFFFFFFFFF_i64 , but still to be good to have option without suffix. Other things could be adding universal UIn64 and unification of Int and Int32 types.

Rendered version

[Apprentice-Alchemist]

but real support for Int64 ( replacing abstract class with the native for the target) will give better performace and will lead to more clean code

That already happen on supported targets (C++, HL, C#, etc) Using eg Float on JS might be possible, but we need to be careful to keep behavior consistent between targets.

I'm also not a fan of the compiler implicitly deciding of the integer type. Numbers without suffixes (and with no type hints) should default to Int and give an error for too large literals. So var x:Int64 = 0xFFFFFFFFFF; should be allowed, but not var x = 0xFFFFFFFFFF;.

Other things could be adding universal UIn64 and unification of Int and Int32 types.

This would be nice, but again, we need to be careful about target-specific behavior.

[flashultra]

In practical is very rarely to use Int above 2147483647, so to not loose performance the current behaviour could be kept i.e. default Int (according to the target) and if someone want consistent overflow behaviour to use Int32. I did some tests on that ( for Firefox: https://www.measurethat.net/Benchmarks/Show/22863/0/int-32-bit-test#latest_results_block ) For Chrome results are better. So, to not lose performance the current solution (Int and Int32) is maybe good.

Int64 for Javascript could be a tricky one. Using Bigint for replacement could lead to loose of performance. I did some test for : Int64 (Haxe) , BigInt (JS) and Float ( Haxe) . The float give wrong result. BigInt give better performance than the current Int64 abstract class. Here is the example: https://try.haxe.org/#669Ae823

	Int64	BigInt	Float
Time	0.04929	0.00570	0.00190
Result	Correct	Correct	Incorrect

Numbers without suffixes (and with no type hints) should default to Int

Default Int looks as a good solution . The other one could be to to use only signed integer values i.e Int < Int64 < BigInt depending of the value.

Adding UIn64 will be nice addition. Some target already have a native one ( C/C++ - unsigned long long ; C# - ulong; ) for other could be emulated or used BigInteger.