_BitInt(N) for fixed width integer aliases #1348
messmerd
started this conversation in
Suggestions
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
C23 introduces
_BitInt(N)
which is a keyword for specifying bit-precise integer types whereN
is the number of bits.See the proposal here: https://open-std.org/JTC1/SC22/WG14/www/docs/n2763.pdf
While C's
int*_t
/uint*_t
aliases are nice, they are (in my opinion) a band-aid over the real problem which is that the entire language was built over a foundation of implementation-defined fundamental types rather than universally understood fixed-width types. C++ inherits this mistake.One example of a negative consequence that resulted from this decision is the lack of a proper 8-bit integer type. There's
int8_t
but this is typically implemented as an alias forchar
, which can cause unexpected issues in C++ such as trying to print anint8_t
but it instead being printed as achar
would. Andstd::byte
doesn't help because it is an enum which lacks the normal operations integer types have.Now, if C++ adopts C23's language features including
_BitInt(N)
, Cpp2 may have to opportunity to use it in its shortened aliases for fixed-width integer types. The following would be valid in both C and C++:This could potentially for the first time provide proper fundamental types to C and C++, including an 8-bit integer type which is actually an 8-bit integer type, while also using the optimal shortened names.
These
_BitInt(N)
types can implicitly convert to and from their fixed-width equivalents in<cstdint>
which would help make their usage easier. Unfortunately there would be some unsettled issues regarding their usage in existing generic code which wasn't written with_BitInt(N)
in mind, though a cast to its correspondingint*_t
/uint*_t
type could be used where needed._BitInt(N)
also carries the property that they do not follow integer promotion rules, which may be desirable. Or not? I do not know.There are likely other issues with this proposal that I haven't thought of yet, but I'd like to see what people think of it. Could it actually work?
Beta Was this translation helpful? Give feedback.
All reactions