Arbitrarily sized ints #328

New Issue

2025-12-30T01:23:34+01:00

adam commented

2025-12-30 01:23:34 +01:00

Originally created by @bioball on GitHub (Jul 29, 2025).

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?

Originally created by @bioball on GitHub (Jul 29, 2025). 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`?

adam commented

2025-12-30 01:23:35 +01:00

@odenix commented on GitHub (Aug 14, 2025):

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 commented on GitHub (Aug 14, 2025): 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.

adam commented

2025-12-30 01:23:35 +01:00

@bioball commented on GitHub (Aug 14, 2025):

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

@bioball commented on GitHub (Aug 14, 2025): One use-case is to represent IPv6 addresses, which are 128-bit ints.

adam commented

2025-12-30 01:23:36 +01:00

@odenix commented on GitHub (Aug 14, 2025):

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 commented on GitHub (Aug 14, 2025): > 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?

adam commented

2025-12-30 01:23:36 +01:00

@bioball commented on GitHub (Aug 14, 2025):

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 commented on GitHub (Aug 14, 2025): Yeah, possibly. Right now this is implemented as a [package](https://pkl-lang.org/package-docs/pkg.pkl-lang.org/pkl-pantry/pkl.experimental.net/current/net/IPv6Address.html), and backed by a [u128 class](https://pkl-lang.org/package-docs/pkg.pkl-lang.org/pkl-pantry/pkl.experimental.net/current/u128/index.html); that effort is one of the motivations for this issue. Another use-case here is to represent epoch microseconds.

adam commented

2025-12-30 01:23:36 +01:00

@StefMa commented on GitHub (Aug 14, 2025):

The documentation of u128 is 🥇!

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

@StefMa commented on GitHub (Aug 14, 2025): The documentation of u128 is 🥇! > Who was it that said we'd never need more than 64 bits??

adam commented

2025-12-30 01:23:37 +01:00

@odenix commented on GitHub (Aug 14, 2025):

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 commented on GitHub (Aug 14, 2025): > 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`.

adam referenced this issue

2025-12-30 01:24:59 +01:00

[PR #328] [MERGED] Follow HTTP redirects #502

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#328