Bikeshedding: BigInt.sqrt/cbrt vs. BigInt.isqrt/icbrt

[js-choi]

Most programming languages that include the integer square root use the name isqrt instead of sqrt. Some of them do use sqrt for integer square roots.

• isqrt in generic namespace: Common Lisp, Crystal, Julia, Maple, PARI/GP*, Python, Racket*, SageMath, Scheme*, Tcl
• isqrt in integer namespace/class: Rust
• sqrt in integer namespace/class: Chapel, Java, Ruby, Zig

(Languages marked with * spell out isqrt using words like integer-sqrt.)

Notably, if we name the BigInt root functions BigInt.isqrt/icbrt instead of BigInt.sqrt/cbrt, then this would point towards also including a Math.isqrt/icbrt for numbers.

• Should we name the BigInt root functions BigInt.sqrt/cbrt vs. BigInt.isqrt/icbrt?
• If we do go with BigInt.isqrt/icbrt, then, in a future proposal (not this one), should we consider Math.isqrt/icbrt for numbers?

I would personally like integer square roots to consistently be isqrt across both bigints (BigInt.isqrt) and numbers (Number.isqrt). If integer square roots are useful on bigints, then they'd be useful on integer numbers too.

CC: @bakkot, @waldemarhorwat, @ljharb

[ljharb]

the "i" is already implied, pretty explicitly, by the "Int" in "BigInt" - i don't see the point in including it here.

[Rudxain]

To avoid repeating myself: rust-lang/rust#89273 (comment)

[ljharb]

It's already an int - it can't ever mean anything other than "isqrt". JS only has Number and BigInt, so that comment's discussion of float types doesn't apply.

[js-choi]

I think the key question here is if we would later add an integer square root function for numbers, Math.isqrt.

If yes, then we probably should go with BigInt.isqrt, to match Math.isqrt.
If not, then we probably should go with BigInt.sqrt.

I’m personally mildly inclined toward ”no, we won’t ever add a Math.isqrt, but it’s still worth discussing a little, since it still may be useful to have a faster version of Math.sqrt then Math.floor.