# Type domain (static) integers

**URL:** https://discourse.julialang.org/t/type-domain-static-integers/118568
**Category:** Internals & Design
**Tags:** discussion, integer
**Created:** [August 24, 2024, 4:52pm UTC](https://discourse.julialang.org/t/type-domain-static-integers/118568 "2024-08-24T16:52:11Z")
**Posts on this page:** 1
**Showing post:** 13

<div class="post-metadata">

### Author: ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [August 26, 2024, 2:02pm UTC](https://discourse.julialang.org/t/type-domain-static-integers/118568/13 "2024-08-26T14:02:17Z")

</div>

> [@jakobnissen](#):
>
> It seems to me that the major motivation for static integers is to move computation from runtime to compile time.

Type domain integers _are_ the motivation. Types are great:

- they can be dispatched on
- you get type safety automatically, instead of having to implement various run time checks
- they allow elegant compile time computation

> [@jakobnissen](#):
>
> somewhat understandable, as we kind of have to do this in Julia to get compile time computation, as it is now

Really don’t see where you’re coming from. Julia’s powerful type system is one of the best things about Julia.

> [@jakobnissen](#):
>
> I would much rather see a solution where constant propagation was beefed up.

Already addressed this in the above reply, improvements to constant propagation are independent of and complementary to type domain integers.

> [@jakobnissen](#):
>
> I would think that what one would want most of the time is constant evaluation rather than specialization, and only specialization some of the time.

Not sure what you mean.

> [@jakobnissen](#):
>
> Type-level integers force specialization all the time.

There’s `@nospecialize` and `@nospecializeinfer` when necessary.

> [@jakobnissen](#):
>
> I don’t really understand the advantage over using `Val`. Sure, you can do `StaticInt(1) + 1`, but what is the advantage of this over unwrapping the `Val` to an integer, then doing your operations?

1. This is like asking, “why write Julia when there’s assembly language”. It’s ugly and you’re giving up on generic code. It also AFAIK puts more pressure on Julia’s compiler than my design, and results in failures sooner (for less recursion depth). And the inference is worse.
2. As noted above, my design is more expressive than that. E.g., there are types such as `NegativeInteger`, `NonnegativeInteger`, `PositiveInteger`, etc. These all subtype `TypeDomainInteger` and it’s possible to express other types, such as `GreaterThanOne`, etc. Positives also subtype nonnegatives, of course.

> [@jakobnissen](#):
>
> It raises the uncomfortable question about other static values. What about floats or Chars?

This is addressed above. `TypeDomainFloats` may perhaps a good idea, but they’re less fundamental than type domain integers. TBH I don’t think I’d ever use type domain floats, but type domain rationals would certainly be nice. Will probably make a package for type domain rationals. In any case this tangent isn’t very relevant.

> [@jakobnissen](#):
>
> The fact that the underlying problems (specialization and compile-time computation)

Don’t understand this. Underlying problems of what?

> [@jakobnissen](#):
>
> the proposed solution only solves it for integers

Yeah, and I’m quite proud of the type safety.

---

_[View the full topic](https://discourse.julialang.org/t/type-domain-static-integers/118568)._