>From my personal understanding, the intN_t aliases provided by the standard are merely for your convenience to quickly locate them. In reality, for the sake of maintainability, you should define your own type aliases based on the intN_t aliases.
Imagine one day you write a piece of software that uses 8 bits to store the length of a certain name. You carry this assumption across various modules of the software, so much so that int8_t is scattered everywhere in the code. Years later, you realize 8 bits are no longer sufficient, and you want your software to support longer names. At that point, you’ll find it extremely difficult because int8_t is used everywhere in the program, and you can’t distinguish whether it represents the length of a name or serves some other purpose. This was a very common issue in the last century.
Therefore, the correct approach is to define using nlength_t = uint8_t;, treating nlength_t as the type for name lengths. This way, you can quickly adjust its actual width without needing to discern its purpose. This is also why size_t is so important—it is designed to be as large as possible to handle as much data as needed.

Thus, abbreviating intN_t doesn’t make much sense. On the contrary, they should be used cautiously. Although today this issue is no longer as severe, since people have grown accustomed to using 32-bit and 64-bit numbers, which are generally large enough.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Radu Ungureanu via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, July 2, 2025 0:24
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Radu Ungureanu <radu.ungureanu_at_[hidden]>
Subject: [std-proposals] Shorter fixed-width integer types

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://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3D%2522typedef%2Buint8_t%2Bu8%2522%2Blanguage%253AC%252B%252B%2B%2BNOT%2Bis%253Afork%26type%3Dcode&data=05%7C02%7C%7C02e4767ae632456b8a2308ddb8bbc995%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638869838889201018%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aLPUpa68i5wfRw7SqJiNEJKMvgaPKFc3pj4wQW0wkYg%3D&reserved=0<https://github.com/search?q=%22typedef+uint8_t+u8%22+language%3AC%2B%2B++NOT+is%3Afork&type=code>
and
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3D%2522using%2Bu8%2B%253D%2522%2Blanguage%253AC%252B%252B%2B%2BNOT%2Bis%253Afork%26type%3Dcode&data=05%7C02%7C%7C02e4767ae632456b8a2308ddb8bbc995%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638869838889219053%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zwxEOAyD1t1sCkncy9a8UybvYYszkiuPPuvXmIzuhkA%3D&reserved=0)<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://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=05%7C02%7C%7C02e4767ae632456b8a2308ddb8bbc995%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638869838889227861%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FD3yw9T9ggBAclyEzJE0mPWgAab3eNq4eBhU1PC1UhQ%3D&reserved=0<https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>