conjure
conjure copied to clipboard
palantir
Specification for an integer64 type
We have several projects extensively using 64-bit integers which cannot be migrated to integer53 (safelong).
I think the primary thing that needs to be figured out here is how to support this on the frontend (Javascript/Typescript) side -- that was the entire reason for the "SafeLong" construct.
It looks like there's something called Long.js and there seem to be Protobuf Javascript implementations that used this to support 64-bit integers (https://github.com/dcodeIO/protobuf.js/issues/1), but we would probably have to flesh this out a bit more for Conjure.
Once we figure out the Javascript/Typescript story, I believe support should be pretty straight-forward for other languages.
This problem would go away with a serde layer in the conjure ts client, so I suggest we'll punt on int64 until we have ts-conjure-serde.
Can you clarify what you mean? Even if a ts-conjure-serde exists, a new integer64/long/long64 would still have to be declared by the Conjure specification, right?
Interestingly, typescript 3.2 now has a bigint type which is enabled if you target esnext (expecting this proposal to be ratified: https://github.com/tc39/proposal-bigint).
We could emit code that uses bigints (which will be fast in modern browsers) and use this polyfill to ensure we don't drop old browsers: https://github.com/GoogleChromeLabs/jsbi
While I don't think we can use bigint until we have a typescript ser/de layer, we can move forward with support for the conjure integer64 type as long as we get the wire format correct.
The proposed bigint type does not include changes to json parsing, so we will need to serialize over the wire using a type that is not a json number. Much like our UUID type, we can serialize integer64 values json strings, I propose using base-10 representation in a json string value.
When we implement the ser/de layer we can apply bigint parsing and expose more ergonomic types to typescript consumers.
Thoughts?
I agree that it seems reasonable to move forward without waiting on full first-class Typescript support.
@iamdanfox @carterkozak Are there any updates on TS serialization support (which seems to be the blocker, looking at the RFC PR above)?
If implemented, this would produce a string value for TS consumers (prior art: uuid, datetime, etc)
Right. The last comment was 1.5 years ago, so I guess I'm asking if this is still blocked on anything on the TS support side or anything else, or if it's only blocked on prioritization at this point. (FWIW: It looks like BigInt is now supported natively across all major browsers: https://caniuse.com/bigint)
This all seems reasonable from the go-infra side of things. If we come to consensus on the RFC I would be happy to prioritize the work to get this into conjure-go.
