New Issue: [Library Stabilization] BigInteger module status

17616, "lydia-duncan", "[Library Stabilization] BigInteger module status", "2021-04-29T23:43:59Z"

The BigInteger module today provides locale support for GMP computations and operations on a bigint type (which is larger than a standard int/uint). This module does not take a strong position separating or unifying itself with the GMP module on which it relies. For stabilization of this library, there are three paths we could take:

  1. Merge the contents of this module back into the GMP module
  2. Make this module's API feel more independent of GMP, by adjusting the interface in ways that feel more "Chapelerific"
  3. "Both" of the above - merge the current contents of this module into GMP and make a new module (potentially with the same name while renaming the new submodule of GMP to be GMPBigInteger or something) with the more "Chapelerific" interface.

In the meeting, it sounded like there was generally a desire for a Chapelerific version, implying that option 2 or 3 would be the way to go.

Things to consider when deciding:

  • GMP module currently doesn't support interactions with its types across locales. Locale operations are handled in the bigint versions, so without a clear connection users might feel they need to do more to handle those situations when working with GMP.
  • The GMP module and the BigInteger module have a circular dependency - BigInteger needs GMP for the functions it calls as part of its implementation, and GMP needs BigInteger to support the GMPRandom class.
    • We could move the GMPRandom class into the BigInteger module. Making it part of a submodule would make looking for it there more natural.
    • We could make the GMPRandom class rely on the internals of the bigint type, which are already present in GMP.
    • We could do both.