I find the Motivation of the RFC not ‘motivational’ enough. It seems the main motivation is interop with C bitfield structs, which is fair, however bitfields are somewhat niche even in C and it is not clear if the RFC is intended to solve just that problem or more and if it is the right solution.
Additionally, the C MipsInstruction example itself is questionable, since C struct bitfield layout is implementation-dependent, ie. in standard portable C you should not use bitfields to decode/encode a mips instruction.
Finally, as @comex pointed out, with const generics custom-width integers would be best implemented in a library.
I personally think that both arbitrary-bitwidth integers and ranged integers are things that should belong in a library, not as language primitives.
I do not see anything about these types that prevents them from being implemented as a library (after Rust supports const generics) and requires them to be language primitives.
I believe that the language should be kept minimal and things should only be added to std (even more so for the language itself) if and only if they really genuinely provide big advantages over a library-based solution.
Why not wait for const generics to land, and then experiment with writing libraries to work with arbitrary-bitwidth integers, ranged types, arbitrary-dimension arrays, fixnums, etc… before writing any RFC to try to add any of this to the language? I think it is important to first get a clear idea of any limitations/drawbacks of a library-based solution.
Const generics merely allocate syntax for such types, which in fact is used by this very proposal. The meat of this feature is restricting the range of valid bit patterns for a given type, which is an ABI decision ultimately made by the compiler. Unless Rust provides a generic facility allowing user code to manually specify all valid bit patterns for a given type, restricted-range types will require dedicated support from the compiler, and types with dedicated compiler support belong in core (and std, but preferably core).
So excuse me, but this suggestion seems pretty nonsensical.
I think the suggestion isn't nonsensical, but rather that an RFC should propose a general layout control mechanism so uint<N> can be a library addition rather than "builtin types".
See the NonZeroU32 discussions for speculation about such a thing. As a strawman, #[repr(transparent)] struct BasePlaneChar(u16); unsafe impl RestrictedRange for BasePlaneChar { const VALID: RangeInclusive<u128> = 0xE000 ..= 0xD7FF; }.
Yes, this looks like the sort of thing I had in mind. But notice how you used a trait in your strawman syntax: that trait will have to be declared as existing somewhere, and the most natural place for it is core. So something is going to be added to the standard library anyway, unless it’s done entirely with attributes.
(Given that this is a strawman, let me refute it: it doesn’t seem general enough to cover multiple ranges, or alignment bits in pointers, and the range you did write is written backwards. Which is confusing, even if I can assume it to be valid by imagining circular topology for ranges.)
Either way, merely saying ‘const generics’ without further elaboration doesn’t really answer the question of how to address this use case. Which is my real point here.
Re #[repr(bitfields)], I've got a draft RFC for a much more general feature, applicable to individual fields: I named it #[compact]. Might post it soon.
Or, in fact, bitfields in C. Sure, they are not as flexible as this proposal, but they do serve as (part of the) motivation for this feature, and therefore count as precedent.
