Proposal: Add BigInt support to Gren for correct 64-bit integers and future-proof interop

[sldab]

Problem

Gren currently relies on Int, which maps to JavaScript Number and inherits its precision limits. This causes silent correctness issues in multiple important domains:

• Binary formats (Protobuf, Cap’n Proto, etc.)
  • These formats natively support int64 / uint64
  • JavaScript Number cannot represent 64-bit integers exactly
  • Writing correct decoders today requires lossy conversions, strings, or hacks
• Time (Posix)
  • Posix timestamps backed by Int are affected by the Year 2038 problem
• Other common cases
  • IDs (Snowflake / database keys)
  • File formats, network protocols
  • Any exact integer arithmetic beyond 53 bits

Without BigInt, Gren cannot safely model many real-world data formats or interoperate losslessly with systems written in Rust, Go, C++, Java, etc.

Proposal

• Introduce BigInt as a first-class type in Gren
• Allow libraries (and potentially core types like Posix) to use BigInt where exact integers are required
• Provide explicit conversion APIs between Int and BigInt when needed

Why BigInt?

• Native JavaScript support (ES2020, widely available)
• Exact integer semantics (no rounding or precision loss)
• Eliminates string-based workarounds in decoders
• Enables correct Protobuf / Cap’n Proto implementations
• Solves the Year 2038 problem instead of postponing it

Compatibility

• Internet Explorer does not support BigInt, but IE is deprecated and effectively unused in 2026
• Now is still a good moment to introduce breaking changes (e.g. Posix) to APIs

Summary

Without BigInt, Gren cannot correctly represent 64-bit integers, which limits interop, correctness, and long-term viability. Adding BigInt support would unlock entire classes of libraries and make Gren safer and more future-proof by design.

[robinheghan]

Thank you!

We're pretty certain that we will add either 64-bit ints or BigInt support in the future.