Non-negative integer types

language design
21

This is pretty much exactly what I'd like to see eventually. It would "just work" and would trivially have niche value optimization, which is a great benefit to top it off. If I could implement it in user code, I would, but it's simply not possible.

2 Likes
22

If you felt like taking on a(nother) project, I think the first plausible lang step here is actually figuring out how to have compile-time unbounded integers for use in const generics.

Right now you have to pick which limited-size integer type to use, and for a bunch of stuff there just isn't a good answer. It would be really cool to not have to choose for things that aren't runtime values anyway. And that'd be useful & stabilizable independently from the bigger project of ranged integers.

23

Proper ranged integers is on my list of things to do, but it's quite low priority.

I actually don't think it would be terribly difficult to have unbounded integers in const generics. The parser already handles any number of digits, and the compiler has a bigint type (as library code).

1 Like
24

Do you have any example code that uses it?

25

That uses what?

26

Sorry, I should have been more clear. Have you written anything that uses deranged?

27

I have experimentally used it with time, but nothing that was ever committed or published.

28

I would add that a good example of the holy grail here would be Zig's primitive types e.g. u1 , u2, u3, etc. all which can be efficiently packed if a struct is marked to do so.

In addition to the integer types above, arbitrary bit-width integers can be referenced by using an identifier of i or u followed by digits. For example, the identifier i7 refers to a signed 7-bit integer. The maximum allowed bit-width of an integer type is 65535.

29

I disagree, actually, because those are just modulo-a-power-of-two, and have all the same overflow problems. The point of my "holy grail" post is in things expanding to the the extent necessary to never have overflow issues, but not more. And because of the careful bounds on the types, there's also infallible divide-by-zero for types with a lower bound above zero -- but all those zig types include 0.

We could add u1, u2, etc to Rust relatively easily. After all, LLVM already supports i1 though i8388608 (although backends probably don't have great support for them, as seen when we added i128 & u128 to Rust).

3 Likes
30

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.