Stream: ideas

Topic: Merge Num.pow and Num.powInt

Brendan Hansknecht (Jun 02 2023 at 16:09):

I think we should merge Num.pow and Num.powInt.
It would just be Num.pow : Num a, Num a -> Num a

My main reasons why:

• Roc has a type system that can generate the correct version of Num.pow based on type. Just like we do with most Num builtins.
• This is the only function that is split this way. There is no other Num.somethingInt function in the standard.
• Both functions fundamentally do the same thing, so I don't think there would be any surprises if they are merged.

Only con off the top of my head:

• pow on Integers is more likely to overflow (which causes a panic in roc if not checked). So having explicitly powInt would make it easier to identify these likely overflow cases.

Given we will have powChecked and users can always cast to larger types or to floats if they want to avoid overflow, I personally don't see this as a big concern.

Anton (Jun 02 2023 at 17:18):

If we can generate based on type it's all good by me :)

Martin Stewart (Jun 03 2023 at 08:42):

I thought Num.powInt was separated because it needs to produce an err if you write Num.powInt 2 -1 (otherwise you have Elms problem where this function says it returns an int but actually it’s a float)

Anton (Jun 03 2023 at 09:43):

Good point!

Brendan Hansknecht (Jun 03 2023 at 13:58):

That would be a very intelligent reason to separate pow from powInt. In our current cases, powInt does not return a result. Instead, on negative values, it just returns 1 (Just learned this by testing in the repl).

Brendan Hansknecht (Jun 03 2023 at 14:00):

Oh, also, powInt is broken. If the value overflows, it just returns the initial number. So Num.powInt 2 200 is 2 (I'll file a bug for that).

Brendan Hansknecht (Jun 03 2023 at 14:05):

Two thoughts on options with context around negative numbers:

1. Just make Num.pow on integers, with a negative power that would return a fraction, truncate just like int operations normally do. So Num.pow 2u32 -1 would just return 0. Cause that is the correct answer as an integer.
2. Keep around Num.powInt, but require the second value to be a U8. That gets rid of the negative number problem and a U8 can store enough values that it can overflow any integer type even when raising 2 to a power.

Last updated: Jun 16 2026 at 16:19 UTC