Checked a few other places where long long is used, like AudioData, Blob, and File and all of them return a JS number in corresponding properties, not BigInt. I'm 95% sure none of these support BigInt, remaining 5% certainty could be added by writing actual tests. I personally vote for either keeping these Int32 as proposed, or creating a new union type. Just riffing:
enum JSNumber: ExpressibleByIntegerLiteral, ExpressibleByFloatLiteral {
case integer(Int32)
case float(Double)
// ...
}
Rust folks have a similar issue, where
long longshouldn't be mapped toInt64, which is bridged toBigInton JS side. https://github.com/rustwasm/wasm-bindgen/issues/800Checked a few other places where
long longis used, likeAudioData,Blob, andFileand all of them return a JS number in corresponding properties, notBigInt. I'm 95% sure none of these supportBigInt, remaining 5% certainty could be added by writing actual tests. I personally vote for either keeping theseInt32as proposed, or creating a new union type. Just riffing:Should we add such type to JSKit then?
cc @kateinoigakukun
Originally posted by @MaxDesiatov in https://github.com/swiftwasm/WebAPIKit/issues/42#issuecomment-1125355976