AFAIK std::byte and uint8_t are different beasts.   -----Ursprüngliche Nachricht----- Von:Radu Ungureanu via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 01.07.2025 20:00 Betreff:Re: [std-proposals] Shorter fixed-width integer types An:Jonathan Wakely <cxx_at_[hidden]>; std-proposals_at_[hidden]; CC:Radu Ungureanu <radu.ungureanu_at_[hidden]>; > 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] <mailto: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] <mailto: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] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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