Implement Map<Int64>

[ncannasse]

ATM, we have Int/String/Enum/Object maps, but not Int64 which is necessary in some cases. Haxe should provide a default implementation, then allow some targets to have an optimized one (HashLink for instance has native support for them). See also #9872

[farteryhr]

i have a bad idea... consider a big change that, for those scripting languages who doesn't natively support Int64, let Int64 be an abstract over String, with the underlying content like fixed-16-hexdigit (such that ordered comparison works well (like for balanced tree) (oh seems for signed int64 it still needs some tweak, like store that xor'ed with bit63, but will be confusing when being directly inspected)).

since it makes trouble on being key of map because it's actually Object, defining it as immutable is just not enough, it's still reference type. strings in most scripting languages are immutable and value type, and key of dicts since day 1....

also, as far as i can see we don't seem to expect it to be too blazing fast on doing emulated arithmetic (see the current divmod, parse/toString, clamp... though i'm not sure which are really in use....), so i think it's acceptable to reparse on-the-fly (hexdigits also makes good use here) and assemble the string each time when doing arithmetic.

https://replit.com/@farteryhr/Int64HighLowToFromString by the way, i made some conversion routine for those assuming we can always use int53 (that's double) but Int64 is processed as high&low parts. if toString decimal performance is still desired, it can be used.

i agree int64 might be one of the hardest thing to make both optimized and consistent across targets.