Naming enum variable for `bigint.probab_prime_p` method

Users
1

Hello,
The enum variable name for the bigint.probab_prime_p(renamed) function, chosen temporarily is primeStatus as given below :

enum primeStatus {
    notPrime=0,
    maybePrime,
    isPrime
  };

Other alternative names for the variable can be checkPrime or primality.

Issue Link: [Library Stabilization] Should bigint.probab_prime_p() return an enum instead?
We need some developers and users to share their opinion on the same and help us decide the best name for this variable.

Thanks
-Yash

2

While I suggested it and favor it myself, it is also still up for debate
if we should change this function to return an enum at all, as the GMP
backing implementation returns one of three numbers representing the
primality of the argument. There's been some support, but we'd be
interested in hearing more opinions.

Thanks,
Lydia

1 Like
3

If we keep an enum, I think renaming it primality is pretty attractive if that feels sufficiently accurate (it does to me, though I haven't thought about it for very long). Specifically, I think it's nice when enum names can be short-and-sweet, not requiring any capital letters.

I'm definitely not a big fan of the C approach of using magic integer numbers to encode things, so remain a fan of the enum-rather-than-int approach, and moreso than it sounds like I was in this comment. Specifically, we're providing a bigint type, not a GMP type, so it's OK for there to be slight differences for the sake of making it more Chapeltastic. And though the direct comparison wouldn't pass, the user could cast it to int easily enough. Or we could even overload == between primality values and integrals (though I wouldn't suggest we go down that path until someone uses this and complains about the lack of an int... which I'm guessing might never happen).

-Brad

1 Like