[suggestion] use abstract over String for Int64 on those doesn't natively support Int64 (aka. js, as2, etc.)

we had quite some problems with Int64 because of it being Object where it's not primitive, not value-typed, not immutable, etc.

i'm aware that this is going to involve a lot of code though, it's big. just an idea for maybe the next big version.

earlier i mentioned it here: https://github.com/HaxeFoundation/haxe/issues/11948#issuecomment-2950401135, following is a (further refined) copy of above.

----

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 so many targets.

----

maybe also "i64xffffffffffffffff" for -1 and "u64xffffffffffffffff" for 2^64-1.

interoperability with modern js `BigInt`, `BigInt64Array` is also considerable, and fortunately `BigInt("0xffffffffffffffff")` works as unsigned -- i loved this (hexstring not assumed to be of any *signed* int length to make `0xffffffff==-1`, and -0x1 is not guilty).

No files, tests, or entry points are named. Start by locating the Int64 representation for JavaScript and other non-native targets, then review the mentioned divmod, parse/toString, and clamp paths; done would require an agreed cross-target design and corresponding implementation and tests.

Written by the indexing model from the issue text.