pub enum IntKind {
Show 13 variants
Char,
SChar,
UChar,
Short,
UShort,
Int,
UInt,
Long,
ULong,
LongLong,
ULongLong,
Int128,
UInt128,
}Expand description
The standard integer types, the character types kept apart from them, and __int128.
Char is its own kind rather than an alias for one of the other two. The standard makes
plain char a third type distinct from both signed char and unsigned char even though
it has the same range as one of them, and a compiler that folds it into whichever one the
target picked gets char * and signed char * wrongly deemed compatible.
__int128 is here rather than modelled as a _BitInt(128), because the two are different
types with different layouts: __int128 is sixteen bytes aligned to sixteen on every
target we have, and _BitInt(128) is aligned to its granule, which is eight on x86-64. It
is available everywhere for us, since all three architectures are 64-bit, and GCC has it
on every 64-bit target. It is deliberately not an extended integer type in the sense the
standard means, which is what keeps intmax_t sixty four bits wide the way GCC has it.
Variants§
Char
char, whose signedness is a target property.
SChar
signed char.
UChar
unsigned char.
Short
short.
UShort
unsigned short.
Int
int.
UInt
unsigned int.
Long
long, the width that separates LP64 from Windows LLP64.
ULong
unsigned long.
LongLong
long long.
ULongLong
unsigned long long.
Int128
__int128.
UInt128
unsigned __int128.
Implementations§
Source§impl IntKind
impl IntKind
Sourcepub const ALL: [IntKind; 13]
pub const ALL: [IntKind; 13]
Every integer kind, in rank order, with __int128 last.
The order is what the internal index agrees with, and it is also the order the standard
walks when it picks the type of an integer constant, so a table walk over the candidate
list for a suffix is a walk over a slice of this. __int128 is at the end because that
is where GCC reaches for it: after every standard type has been tried and none of them
was wide enough.
Sourcepub const fn is_signed(self, char_is_signed: bool) -> bool
pub const fn is_signed(self, char_is_signed: bool) -> bool
Whether this type is signed, given what the target says about plain char.
The argument is there because char is the one integer type whose signedness is not
in the standard. It is signed on x86-64 and unsigned on AArch64 Linux, and a compiler
that assumes either one is the source of a whole genre of bug report.
Sourcepub const fn rank(self) -> u8
pub const fn rank(self) -> u8
The integer conversion rank, as an ordering rather than as a number from the standard.
The standard gives no values, only a set of relations, and every one of them is a comparison between two ranks. Signed and unsigned of the same width share a rank, which is what makes the usual arithmetic conversions between them pick the unsigned type rather than the wider one.
Sourcepub const fn flip_sign(self) -> IntKind
pub const fn flip_sign(self) -> IntKind
The same width with the other signedness.
char maps to unsigned char and back to signed char, which is the mapping the
usual arithmetic conversions need and is not a round trip. That asymmetry is the type
system telling the truth: there is no way back to plain char from either of the
other two.