consider ripping out ranged integer types

[BurntSushi]

One of the first abstractions I developed in Jiff was the ranged integer type. It used a very light amount of const integers/generics. Instead, its key innovation was that, when debug_assertions was enabled, it would keep track of its minimum and maximum possible values, computed via the operations performed on that integer. Each ranged integer would carry with it minimum and maximum values. And so every step of the calculation would be checked not just with respect to the primitive integer representation, but with respect to the bounds set for that particular integer type. For example, type Year = ri16<-9999, 9999>.

There are some failings though:

• The ranged integer abstraction seems to inhibit most APIs from being const. See make more of the API const #2 for more on that. Although it's worth pointing out that, even if ranged integers were ripped out, there are still potentially significant hurdles from making more of Jiff's APIs const. But I think it's safe to say more APIs than today could be feasibly made const.
• The ranged integer abstraction increases the use of generics in a variety of places. To make writing code convenient, there are a lot of number: impl RInto<RangedIntegerType> parameters on functions. This probably imposes a hit on compilation times and binary size. Some of this could likely be mitigated through explicit monomorphization, but it would be a huge pain.
• Singe ranged integers aren't a publicly exported thing in Jiff (and they shouldn't be), a lot of APIs are split between the internal "ranged integer" API and the normal public "primitive integer" API. This is annoying.
• While in the beginning, my ranged integer types were catching a lot of numerical overflow bugs, I've found that as of recently, most of the overflows they catch are actually due to incorrect use of the ranged integer types rather than legitimate bugs in the code. Namely, the ranged integers types aren't a perfect abstraction. The minimum and maximums aren't always correctly tracked, especially when there's conditional control flow. Still, maybe they are helping prevent bugs just by virtue of providing very consistent range checks on inputs.

So I'm not sure. I'm currently still happy with keeping ranged integers around, but I wonder if they should be looked at more as a tool that helped me "bootstrap" the library and get the numerical algorithms correct. But that they are more like scaffolding, something to be dismantled now that the library's numerical core is pretty much complete.