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: #11948 (comment), 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).
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: #11948 (comment), 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,BigInt64Arrayis also considerable, and fortunatelyBigInt("0xffffffffffffffff")works as unsigned -- i loved this (hexstring not assumed to be of any signed int length to make0xffffffff==-1, and -0x1 is not guilty).