# StaticBigInt

**URL:** <https://forums.swift.org/t/staticbigint/54545>\
**Category:** Pitches\
**Created:** [January 10, 2022, 5:24pm UTC](https://forums.swift.org/t/staticbigint/54545 "2022-01-10T17:24:06Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [January 17, 2022, 5:45am UTC](https://forums.swift.org/t/staticbigint/54545/23 "2022-01-17T05:45:08Z")

</div>

> [@benrimmington](#):
>
> > [@xwu](#):
> >
> > “Static” is good here but not all storage-but-not-math numeric types will have the restriction that values are immutable; crucially, though, there’s nothing about “static” that clearly conveys the notion that it’s a type meant for storing a numeric value but not for computation.
> 
> The proposed type seems closest to `StaticString` — both provide low-level access to the representation of a literal value. However, we can discuss other names, if there are any suggestions.

Sure, we can discuss the bikeshedding part sometime; that wasn't entirely the point I was trying to make.

Rather, I was trying to raise the point that this type (however it is named) could be the first of possibly a whole family of types which cannot—and, moreover, we deliberately do not desire to—conform to numeric protocols. For example, as I mentioned above, IEEE 754 defines families of "interchange formats" to "support the exchange of floating-point data" that don't also have to be supported "arithmetic formats."

It would be nice™, therefore, if we could have a term (maybe not "interchange") to describe this family of numeric types as distinct from the standard types we support, so that it is clear—as in your answer to @Saklad5, quoted below—that it is not some design shortcoming or temporary implementation limit that causes the numeric APIs not to be there, but rather that it's inherent to the purpose for which the type exists.

My claim is that the "non-arithmetic interchange-ness" of `StaticBigInt` distinguishes this type from `Int` along a _distinct axis_ from its static-ness (à la `StaticString`), which I agree also distinguishes this type from `Int`. I am less interested in debating the precise name of the type at this point, or even whether the "static-ness" of the type is more salient to its name than the "non-arithmetic interchange-ness," only to put it out there that there _is_ this second axis along which the proposed type here is distinct from `Int`.

> [@benrimmington](#):
>
> > [@Saklad5](#):
> >
> > I feel this is another illustration of why the numeric protocols need to be overhauled. They impose an irrational hierarchy through unnecessary protocol inheritance, making them unusable outside narrow (albeit common) use cases.
> 
> I don't think that's true in this case. Most of the numeric APIs (regardless of their place in the protocol hierarchy) can't be implemented by `StaticBigInt` .

---

_[View the full topic](https://forums.swift.org/t/staticbigint/54545)._