On July 1, 2025 7:24:36 PM Radu Ungureanu via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> Aliasing stdint types like uint16_t to shorter names like u16 has become
> a very common practice. This trend has influenced other modern languages
> like Rust, Zig, Cpp2, Carbon and Odin to adopt this. On GitHub, u8 alone
> has lead to the same ~6k lines of code (counted with
> https://github.com/search?q=%22typedef+uint8_t+u8%22+language%3AC%2B%2B++NOT+is%3Afork&type=code
> and
> https://github.com/search?q=%22using+u8+%3D%22+language%3AC%2B%2B++NOT+is%3Afork&type=code).
> These names (int*_t) while precise, are quite verbose and cumbersome to
> use, especially in codebases where dealing with low-level code is the
> norm such as binary loaders or networking tools.
>
> I propose the following to be included in <cstdint>, a approach which
> has been inspired by std::literals:
>
> namespace std {
> namespace ints {
> using i8 = int8_t;
> using u8 = uint8_t;
> using i16 = int16_t;
> using u16 = uint16_t;
> using i32 = int32_t;
> using u32 = uint32_t;
> using i64 = int64_t;
> using u64 = uint64_t;
> using iN = intN_t;
> using uN = uintN_t;
> }
> }
>
> The typical usage of this would be as follows:
>
> using namespace std::ints;
> struct SomeFileFormatHeader {
> u16 magic;
> u32 checksum;
> u32 num_entries;
> // etc...
> }
>
> I have considered putting those in the same namespace as int*_t but that
> would break existing code that already defines those types using the
> help of stdint.

I'm not convinced with the utility of this addition. You're saving 5
keystrokes in the type name but adding 6 in the namespace qualification. I
know you can do "using namespace std::ints;" but this is generally advised
against as it may introduce name clashes, if not now then in the future,
when new names are added in std::ints or in your program.

Another downside is this introduces confusion as to which types to use and
whether e.g. uint32_t and u32 are interchangeable.

I'd like to note that (u)intN_t reflect POSIX and C types, but I don't
think the proposed shorter alternatives are defined in any relevant standard.