pkl icon indicating copy to clipboard operation
pkl copied to clipboard

Arbitrarily sized ints

Open bioball opened this issue 5 months ago • 6 comments

The current Int is an int64. We should support ints that are arbitrarily sized.

One open question here is: should Pkl's numbers be arbitrarily sized? Or should we introduce a new type, e.g. BigInt?

bioball avatar Jul 29 '25 17:07 bioball

What are the use cases, and how common are they?

Retrofitting Int would be a breaking change and might affect runtime and memory performance. It might also increase the likelihood of writing erroneous programs that don’t terminate in a reasonable time.

odenix avatar Aug 14 '25 07:08 odenix

One use-case is to represent IPv6 addresses, which are 128-bit ints.

bioball avatar Aug 14 '25 17:08 bioball

One use-case is to represent IPv6 addresses, which are 128-bit ints.

Shouldn’t these be represented by an Ipv6 stdlib class in any case?

odenix avatar Aug 14 '25 17:08 odenix

Yeah, possibly. Right now this is implemented as a package, and backed by a u128 class; that effort is one of the motivations for this issue.

Another use-case here is to represent epoch microseconds.

bioball avatar Aug 14 '25 18:08 bioball

The documentation of u128 is 🥇!

Who was it that said we'd never need more than 64 bits??

StefMa avatar Aug 14 '25 18:08 StefMa

Another use-case here is to represent epoch microseconds.

FWIW, Java classes such as java.time.Instant don’t use BigInteger anywhere (just long and int).

By the way, if Pkl’s Int was retrofitted to be arbitrarily sized, the Java code generator would need to generate BigInteger.

odenix avatar Aug 14 '25 18:08 odenix