On Tue, 1 Jul 2025 at 18:09, Radu Ungureanu via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > 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.
> The code search isn't meant to be exact, but rather to illustrate an idea
> of how widespread this practice has become.
>
> > 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.
> I understand your concern. However, I think there's value in consistency
> with the rest of the STL (e.g. u16string),
>

But that's a string og char16_t not 'u16' integers, so I'm not sure that is
really a good argument for consistency.



> as well as improved readability and brevity, especially in codebases where
> they are heavily used. It would also help in reducing the duplication
> across codebases since many already define those locally.
> On 01.07.2025 19:56, Andre Kostur wrote:
>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>