# Pre-RFC: Generic integers v2 **URL:** \ **Category:** Uncategorized\ **Created:** [August 7, 2024, 11:00pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326 "2024-08-07T23:00:41Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![SkiFire13](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/skifire13/32/7579_2.png) [@SkiFire13](https://internals.rust-lang.org/u/SkiFire13)\ **Post date:** [August 13, 2024, 4:37pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/62 "2024-08-13T16:37:58Z")
> [@scottmcm](#): > > As a quick demo, here's LLVM generating exactly the same code for `i47` and `i64`: [https://llvm.godbolt.org/z/Tbde7ov67](https://llvm.godbolt.org/z/Tbde7ov67). Note that this is incompatible with `i47` having a niche, since that requires the unused bits to have a fixed value (0 according to the Pre-RFC), but LLVM seems to consider them to be more akin to padding bytes, which can take any value. As a sidenote, is reading those unused bits UB for LLVM? > [@Neutron3529](#): > > Yes. I means, should we use `u/i` instead of `u/i`? > > For example, `i<32>` is `i<32,32>`, and `i<32,8>` use align =1, `i<4,4>` allow use part of a byte. `i<4,4>` would not be a valid type since 1/2 is not a valid alignment. Bit-level alignment doesn't make sense in general, it needs to be a positive amount of bytes and is generally assumed to be a power of 2. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [August 13, 2024, 4:58pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/63 "2024-08-13T16:58:30Z")
> [@SkiFire13](#): > > Note that this is incompatible with `i47` having a niche, since that requires the unused bits to have a fixed value (0 according to the Pre-RFC), but LLVM seems to consider them to be more akin to padding bytes, which can take any value. Note that we'd never store an `i47` in the LLVM we emit, because that doesn't have well-defined semantics. We'd always `zext` or `sext` it (depending on `u<47>` or `i<47>`) to whatever byte size we decide on and store that, which is the point at which things like that niche note would matter. The actual values in _registers_ is LLVM's problem; not something that'd ever be observable by a rust programmer. > [@SkiFire13](#): > > As a sidenote, is reading those unused bits UB for LLVM? It's an `i47`. If you `lshr` it by one 47 times, you're guaranteed to get zero. Asking about the bits above the 47 in the type is like asking what's in the 100th bit of an `i64`. ---
**Author:** ![Vorpal](https://avatars.discourse-cdn.com/v4/letter/v/aca169/32.png) [@Vorpal](https://internals.rust-lang.org/u/Vorpal)\ **Post date:** [August 13, 2024, 5:11pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/64 "2024-08-13T17:11:47Z")
> [@scottmcm](#): > > The actual values in _registers_ is LLVM's problem; not something that'd ever be observable by a rust programmer. What about sending a i42 to/from inline assembly? ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [August 14, 2024, 8:53am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/65 "2024-08-14T08:53:32Z")
> [@clarfonthey](#): > > I'll be honest, I'm a bit confused by what you're trying to advocate for. I assume that the crate you're referencing is `deranged`, in which case, the ranged integers would still be bound by the generic integers here. Due to compiler limitations, yes. What I envision in a future RFC is to have a single type for range-bound integers (without specifying the number of bits). I know this is doable given my previous experiments. The _only_ thing I'm asking is for the naming to be considered. I thought I was extremely clear on that from the start, where I asked > do you have any ideas for forward compatibility with ranged integers name-wise? That remains my question. `uint` is an obvious choice for generic integers that I have no objection to. `int`, on the other hand, has the potential to cause significant confusion with range-bound integers (for which my personal preference is naming them `int`). There is `iN` and `uN` for generic integers that would work nearly as well, while ranged-bound integers have no other easy-to-think-of alternatives. ---
**Author:** ![farnz](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/farnz/32/6587_2.png) [@farnz](https://internals.rust-lang.org/u/farnz)\ **Post date:** [August 14, 2024, 9:33am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/66 "2024-08-14T09:33:34Z")
Bikeshedding on names: how about `uint` and `sint` for "unsigned integer" and "signed integer", leaving `int` unused? This doesn't quite match up to existing Rust `u32` and `i32` types, but is clear about what's intended. Or use `rint` for range integers? ---
**Author:** ![clarfonthey](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/clarfonthey/32/12413_2.png) [@clarfonthey](https://internals.rust-lang.org/u/clarfonthey)\ **Post date:** [August 14, 2024, 5:34pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/67 "2024-08-14T17:34:28Z")
> [@jhpratt](#): > > The _only_ thing I'm asking is for the naming to be considered. I thought I was extremely clear on that from the start, where I asked I do want to consider it; I just want to make sure that the thing being considered is something that both can be done, would be reasonable to do, and makes sense under the `int` name, and I'm not sure both apply here. I haven't looked into this nearly as much as folks like you have, which is why I can't rule this out right now. It's just that, from everything you and others have said, there are still a lot of unanswered questions. I talk about the type of the bounds, but honestly, the bigger issue is how exactly these integers should behave, and what "fixed precision, bounded integers" would look like in the language. Do they just never overflow, always growing bigger each time you perform operations on them? How would assign-operations work for these, or would they just not have them? Do they have overflow, wrapping in their range, in that case? And again, we're deciding to break the symmetry for the name of a fundamental type in the language, going with `uint` and `sint` instead of `uint` and `int` to match `uN` and `iN` everywhere, all because this hypothetical ultimate integer type is going to eventually be maybe be designed in a couple years and then implemented a couple years later? Why can't the ranged integer type just be called `Int`? or `integer`? It feels like it'll be way less used than the existing integer types for sure, since it adds a lot of complexity to bounds when most programs just choose integer types as a way of optimising the size of things in memory, not strictly bounding things in their APIs. Certainly, it would be weird that the generalisation of `i32` is `int<0..=0xFFFFFFFF>` or `sint<32>` and not `int<32>`. Like, choosing the name `int` for the signed, bit-generic integer type makes a lot of sense, and unless ranged integers feel both canonical and implementable in the near future, I don't see why we should use the `int` name for them. They feel canonical mathematically, but they don't feel canonical in the way the language is designed, and that's the bigger issue IMHO. ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [August 15, 2024, 6:39am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/68 "2024-08-15T06:39:11Z")
I don't want to totally derail this thread into a full-on discussion about the precise behavior of range-bound integers. As such I won't be responding to the questions on that regard. Feel free to create another topic if you'd like to discuss it, however. > [@clarfonthey](#): > > all because this hypothetical ultimate integer type is going to eventually be maybe be designed in a couple years and then implemented a couple years later? Generic integers are hypothetical at this point as well. Let's not act as if one is a foregone conclusion and the other is a moonshot. I _personally_ plan on getting around to ranged integers sooner than multiple years out. > [@clarfonthey](#): > > Why can't the ranged integer type just be called `Int`? or `integer`? All primitive types begin with a lowercase letter, and `integer` is quite verbose. > [@clarfonthey](#): > > It feels like it'll be way less used than the existing integer types for sure Likewise for this proposal, for what it's worth. > [@clarfonthey](#): > > and unless ranged integers feel both canonical and implementable in the near future, I don't see why we should use the `int` name for them. If I'm understanding you correctly, you're essentially arguing for a "first come first served" naming basis here? * * * In the pre-RFC, [you bring up](https://github.com/clarfonthey/rust-rfcs/blob/generic-integers-v2/text/0000-generic-integers.md#use-un-and-in-instead-of-uintn-and-intn) using `u` and `i` as an alternative, dismissing them due to conflicts with `let i` (and presumably `u` as well, albeit far less common). I think it's worth noting that values and types live in different namespaces, so the conflict here would be minimal if any. It's [perfectly legal to have a variable named `u8`](https://github.com/rust-lang/rust/blob/0ba9db87e61adcfd9a978188f61c20d9b423a099/tests/ui/weird-exprs.rs#L92-L112), after all. ---
**Author:** ![DragonDev1906](https://avatars.discourse-cdn.com/v4/letter/d/e68b1a/32.png) [@DragonDev1906](https://internals.rust-lang.org/u/DragonDev1906)\ **Post date:** [August 15, 2024, 8:30am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/69 "2024-08-15T08:30:03Z")
> [@jhpratt](#): > > If I'm understanding you correctly, you're essentially arguing for a "first come first served" naming basis here? I'd argue there is a stronger argument for `int` over `int`: `int` directly describes the memory layout, maps directly to existing `iN` and `uN` types, has clear/intuitive behavior in regards to overflow and those are easy/performant to implement and will be familiar to those coming from other languages. To me this feels more like a primitive type (that being closer to the hardware) than `int`, which contains all information to know the memory layout, but does not have a clear mapping to the underlying memory representation. For example: `int<100..=200>` fits into a u8, but which bits/range does it use? `0x64`-`0xc8` (100-200) or `0x00`-`0x64`? There is an argument for both: The first being the actual value, making it trivial to convert to a `u8`, which a lot more functions would accept, the second being sufficient to store the data. You'd probably suggest the first representation. On the other hand you can also define a `int<4294967140..=4294967240>` type (`0xffffff64`-`0xffffffc8`). Does this now mean it's a `u32` because it is trivially convertable? Or does it mean it's a `u8` (`0`-`100`) because that's sufficient or does it mean it's a `u8` that maps via the use of bitwise and/or only to make conversion easier? The last option could a type with a type larger than it'd be needed: `int<0x01f0..=0x02e0>` has a range smaller than 256 but how would it be represented in memory: - u8: 0x00-0xf0 - Converting to the "real" number (u16 or larger) requires addition and requires knowing the minimum from the type when debugging/reverse engineering. - u9/u16: 0x0f-0x1e - Conversion is trivial using bitwise and with 0x0100, but that means there you need at least 9 bits because the range is not well "aligned" - u16: 0x01f0-0x02e0 - Makes the type larger than really needed, but stores the "real" number ### TLDR I'm not trying to argue against ranged/bounded integers, but I think there are still open questions in regards to the memory layout that are not intuitive based on the type alone. The name+generics of the type itself doesn't show/explain the memory representation, which is in my opinion really important for such a basic type like an integer. That direct to-hardware mapping and intuitive memory representation (for anyone familiar with other languages) makes `int` a lower-level primitive than a `int` and thus it should in my opinion have the shorter/more intuitive name. ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [August 15, 2024, 9:00am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/70 "2024-08-15T09:00:51Z")
As I have said, I do not intend to debate the full workings on range-bound integers here, as that is off-topic. However, I will push back against > [@DragonDev1906](#): > > The name+generics of the type itself doesn't show/explain the memory representation, which is in my opinion really important for such a basic type like an integer. Other primitive types — namely pointers, references, and tuples — have largely unspecified layouts with only minimal guarantees. `bool`, oddly enough, doesn't seem to have layout guarantees either: its documentation only mentions that it's 0 or 1 when _cast_ to an integer. Given that there are three primitive types that _already_ don't have specified layouts, this clearly can't be a blocker. ---
**Author:** ![programmerjake](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/programmerjake/32/5893_2.png) [@programmerjake](https://internals.rust-lang.org/u/programmerjake)\ **Post date:** [August 15, 2024, 10:45am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/71 "2024-08-15T10:45:14Z")
> [@jhpratt](#): > > `bool`, oddly enough, doesn't seem to have layout guarantees either it does have layout guarantees: [Boolean type - The Rust Reference](https://doc.rust-lang.org/reference/types/boolean.html#:~:text=An%20object%20with%20the%20boolean%20type%20has%20a%20size%20and%20alignment%20of%201%20each.%20The%20value%20false%20has%20the%20bit%20pattern%200x00%20and%20the%20value%20true%20has%20the%20bit%20pattern%200x01.%20It%20is%20undefined%20behavior%20for%20an%20object%20with%20the%20boolean%20type%20to%20have%20any%20other%20bit%20pattern). ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [August 15, 2024, 6:19pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/72 "2024-08-15T18:19:31Z")
The reference is explicitly not normative. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [August 15, 2024, 7:03pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/73 "2024-08-15T19:03:22Z")
`bool` is size 1 [https://doc.rust-lang.org/std/mem/fn.size\_of.html](https://doc.rust-lang.org/std/mem/fn.size_of.html), and thus must be align 1. ---
**Author:** ![binarycat](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/binarycat/32/12210_2.png) [@binarycat](https://internals.rust-lang.org/u/binarycat)\ **Post date:** [August 17, 2024, 3:22am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/74 "2024-08-17T03:22:21Z")
> [@clarfonthey](#): > > and unless ranged integers feel both canonical and implementable in the near future, I don't see why we should use the `int` name for them. They're already implemented in the layout system, actually. that's how `NonZero` and `NonNull` work. `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` are the attributes (although they can't be tied to generic paramates or even negative numbers) ---
**Author:** ![clarfonthey](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/clarfonthey/32/12413_2.png) [@clarfonthey](https://internals.rust-lang.org/u/clarfonthey)\ **Post date:** [August 18, 2024, 2:03am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/75 "2024-08-18T02:03:40Z")
> [@jhpratt](#): > > I don't want to totally derail this thread into a full-on discussion about the precise behavior of range-bound integers. As such I won't be responding to the questions on that regard. Feel free to create another topic if you'd like to discuss it, however. I think that considering the semantics of them would be worthwhile in this case if we choose to believe that ranged integers are more canonical of a representation than bit-generic integers. That said, I won't push for more details if you don't want to provide them here. > [@jhpratt](#): > > All primitive types begin with a lowercase letter, and `integer` is quite verbose. The reason why I mention `Int` as an option is that it's not _necessarily_ guaranteed that said ranged integer type would be a primitive. For example, `NonNull` is entirely implemented on top of existing primitive types, with `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` as mentioned. I don't see why ranged integers couldn't have similar treatment, especially if we're assuming that they could easily coexist with bit-generic integers. I also think that ultimately, it would be good longer-term to allow coercing literals into types like `NonNull`, and the "primitiveness" of a type shouldn't affect whether we're allowed to do that. The reason I mentioned `integer` is actually because the compiler refers to integer literals as `{integer}`, and thus it feels appropriate for ranged integers in this case. We would effectively be replacing `{integer}` with a proper `integer` type, since these literals would also be used as the bounds for the type. > [@jhpratt](#): > > If I'm understanding you correctly, you're essentially arguing for a "first come first served" naming basis here? I mean, that _is_ how we've decided Rust works as a language. Since names can't be changed, the existing `iN` and `uN` types are forever enshrined as the primitive integer types, and it makes sense to mimic the name of a bit-generic integer with the ones that already exist in the language. Except, as you mention… > [@jhpratt](#): > > In the pre-RFC, [you bring up](https://github.com/clarfonthey/rust-rfcs/blob/generic-integers-v2/text/0000-generic-integers.md#use-un-and-in-instead-of-uintn-and-intn) using `u` and `i` as an alternative, dismissing them due to conflicts with `let i` (and presumably `u` as well, albeit far less common). I think it's worth noting that values and types live in different namespaces, so the conflict here would be minimal if any. It's [perfectly legal to have a variable named `u8`](https://github.com/rust-lang/rust/blob/0ba9db87e61adcfd9a978188f61c20d9b423a099/tests/ui/weird-exprs.rs#L92-L112), after all. I… legitimately didn't even consider this, and you're probably right. It still feels _weird_ to have single-letter types effectively in the prelude, but honestly, this makes `u` and `i` feel more canonical than `uint` and `int`. And that would solve the issue of `int<...>` being for ranged integers. I'll have to think about it a bit more, but honestly, I feel silly and will probably update the RFC to just use the single-letter names. ---
**Author:** ![pitaj](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pitaj/32/11262_2.png) [@pitaj](https://internals.rust-lang.org/u/pitaj)\ **Post date:** [August 18, 2024, 2:39am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/76 "2024-08-18T02:39:02Z")
Have you considered `uint` and `sint`? I haven't seen any responses to those suggestions. ---
**Author:** ![Uther](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/uther/32/6225_2.png) [@Uther](https://internals.rust-lang.org/u/Uther)\ **Post date:** [August 18, 2024, 4:54am UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/77 "2024-08-18T04:54:28Z")
> [@jhpratt](#): > > All primitive types begin with a lowercase letter. To me it is an issue to fix rather that a good guideline to follow for new types. I'm not sure it is technically possible but in the way I would like to introduce ranged types is by deprecating current primitives integers and replacing them with their uppercase counterpart that support ranges as an optional parameter. They would act like the current integer primitives if the range is not specified. According to this vision, generic integers could be `I` or `U` with an optional second parameter for the range, and automatically sized integers would be `Int` ---
**Author:** ![binarycat](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/binarycat/32/12210_2.png) [@binarycat](https://internals.rust-lang.org/u/binarycat)\ **Post date:** [August 18, 2024, 6:52pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/78 "2024-08-18T18:52:45Z")
> [@Uther](#): > > According to this vision, generic integers could be `I` or `U` with an optional second parameter for the range, and automatically sized integers would be `Int` this is a very bad idea, single letter uppercase types are conventionally used for generic type paramaters, and `I` and `U` are quite common for this purpose. ---
**Author:** ![binarycat](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/binarycat/32/12210_2.png) [@binarycat](https://internals.rust-lang.org/u/binarycat)\ **Post date:** [August 19, 2024, 4:57pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/79 "2024-08-19T16:57:30Z")
> [@SkiFire13](#): > > However making the generic parameter any integer type has the issue of circular reasoning: `u32` would be defined as `uint<32u32>`, where `32u32` has type `u32` but that's what's being defined! this is only the case if we make the current primitive integers into aliases for generic integers. there's a few arguments against that, for example, crates that have integer-related traits may want to have a faster impl for regular ints, then a generic impl for generic ints, and they probably don't want to wait for specialization in order for that to happen. ---
**Author:** ![SkiFire13](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/skifire13/32/7579_2.png) [@SkiFire13](https://internals.rust-lang.org/u/SkiFire13)\ **Post date:** [August 19, 2024, 5:58pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/80 "2024-08-19T17:58:48Z")
> [@binarycat](#): > > this is only the case if we make the current primitive integers into aliases for generic integers. The current RFC lists generalizing code for integers and decluttering documentation as two of the main goals and they can only be achieved if the current primitive integers become aliases for generic integers. Otherwise you'll actually make those situations worse, since you're adding yet another integer type which will be harder to generalize code for (all the existing macros don't expect the integer types to have a generic parameter). ---
**Author:** ![clarfonthey](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/clarfonthey/32/12413_2.png) [@clarfonthey](https://internals.rust-lang.org/u/clarfonthey)\ **Post date:** [August 19, 2024, 10:44pm UTC](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326/81 "2024-08-19T22:44:46Z")
My general response is that adding an `s` for signed is at least not what we've been doing throughout the rest of the language. We use `iN`, not `sN`, so, it feels a bit out of place. Like mentioned, `u` and `i` _do_ seem canonical despite my (wrong) assumptions earlier, so, it feels right to just go with them instead of changing up the formula. [Previous page](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326.md?page=3) [Next page](https://internals.rust-lang.org/t/pre-rfc-generic-integers-v2/21326.md?page=5)