Hmm, the code search you provided also showed instances where the type
wasn’t directly translated, like going from u8 to boost::uint_fast8_t.

Afraid I’m not convinced that adding a bunch of aliases into the standard
for other types in the standard, and those aliases provide no additional
semantic meaning, is warranted.


On Tue, Jul 1, 2025 at 9:24 AM 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.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>