You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
int64 is too big for JavaScript's Number type (IEEE-754 double-precision floating point).
JavaScript looses precision on values higher than Number.MAX_SAFE_INTEGER (9007199254740991) and rounds them up.
Technically, we could error out in JS runtime, if we notice values bigger than that if we decide to keep Number in JS/TS generators.
webrpc is really only compelling if it creates an explicit contract between client and server. In that sense, it should try to ensure that numbers are treated the same way regardless of the environment in which they are used. However,
both int and uint are supported in webrpc schemas, but by convention these refer to the default width supported by language and platform which may vary between client and server. In addition to adding BigInt support, I'd consider removing int and uint from support for this reason.
while using BigInt in JS/TS (and by extension Dart) is probably necessary, a BigInt primitive type in webrpc weakens the contract of the schema that other declarations like uint64 and int32 provide. My guess is that if a developer thinks they need an arbitrarily-sized integer, they havent really thought about the design of their system. I'd rather see webrpc support int128, int256, etc.
int64
is too big for JavaScript'sNumber
type (IEEE-754 double-precision floating point).JavaScript looses precision on values higher than
Number.MAX_SAFE_INTEGER
(9007199254740991) and rounds them up.Technically, we could error out in JS runtime, if we notice values bigger than that if we decide to keep
Number
in JS/TS generators.Current workarounds:
Proposal - switch to BigInt
I think it would make sense to represent
int64
asBigInt
in JavaScript and TypeScript generators. BigInt looks to be well supported.The text was updated successfully, but these errors were encountered: