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

That is true, it might be a bit of a stretch to go to it directly. I
should have been more explicit about my reply. What I meant to say was
how the STL has adopted shorter equivalents to types in some places. For
example:

  * std::string -> std::basic_string<char>
  * std::chrono::* -> std::chrono::duration
  * std::byte -> uint8_t
  * std::nullptr_t -> decltype(nullptr)

On 01.07.2025 20:38, Jonathan Wakely wrote:
>
>
> 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
>> <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
>> <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
>