Stream: ideas

Topic: the Nat type

Qqwy / Marten (Jun 14 2022 at 09:26):

I've been reading through the 'TUTORIAL' and most other documentation files to get up to speed with Roc.
Most of the design choices are fairly obvious and well-described.
However, one thing that broke my principle of least surprise, is the naming of Nat for the type of sizes.
The reason being that it goes against how the name is used in plain math and other programming languages, where Nat is an unsigned big integer type.

Why was the name Nat chosen for this in the current design of Roc over, say, Size?

Richard Feldman (Jun 14 2022 at 12:35):

we had a discussion about that on Zulip a year or two ago, and as I recall, Size was one of the options we discussed!

Richard Feldman (Jun 14 2022 at 12:35):

I seem to remember one of the concerns there was that it suggested dimensionality, when it often wouldn't be a dimension

Richard Feldman (Jun 14 2022 at 12:36):

e.g. List.get : List elem, Size -> Result elem [OutOfBounds]

Richard Feldman (Jun 14 2022 at 12:36):

that argument is an index, not really a "size"

Richard Feldman (Jun 14 2022 at 12:36):

if that makes sense

Richard Feldman (Jun 14 2022 at 12:37):

according to ISO-80000-2, "natural numbers" are non-negative integers

Richard Feldman (Jun 14 2022 at 12:43):

so although it's true that other programming languages use a different definition of Nat from mathematics, it's also true that PLs don't agree either - e.g. in some languages Nat is arbitrary-sized, in Unison it's fixed at 64-bit; in all the languages I know of that have a Nat type, it starts with 0, whereas mathematics has it start with 1

Richard Feldman (Jun 14 2022 at 12:43):

but they are all nonnegative integers, which is true of Roc's Nat too

Richard Feldman (Jun 14 2022 at 12:45):

the name doesn't imply that the size varies based on target, but the same is true of OCaml; OCaml's Int type is closest to Rust's isize (but with 1 bit less available), so it varies by target even though the name Int doesn't suggest it might - so there's precedent for that naming approach too

Richard Feldman (Jun 14 2022 at 12:46):

so overall Nat seemed consistent with existing precedents in that it represents a nonnegative number (the only consistent thing about how it's used across PLs and math, and so the one property people can reliably expect from a Nat type)

Qqwy / Marten (Jun 14 2022 at 13:02):

Tangentially related to this by the way: Are there plans to support bigints at some future date, or is it a conscious choice (for performance/compatibility reasons?) to not support them at all?

Richard Feldman (Jun 14 2022 at 13:11):

I'm open to it in theory, but i128 goes up to several undecillion, so I'd want to hear from people who have use cases where that isn't big enough first :big_smile:

Last updated: Jun 16 2026 at 16:19 UTC