>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@lists.isocpp.org> on behalf of Radu Ungureanu via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Wednesday, July 2, 2025 0:24
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Radu Ungureanu <radu.ungureanu@socopon.com>
Subject: [std-proposals] Shorter fixed-width integer types