> Did you also look for the number of times identifiers like "u8" are
used for other things, such as an 8-bit variable? "uint8_t u8 = 123;".
Or for when the combination is used in connection with UTF-8 ? Or
someone has written "int u1, u2, u3, u4, u5, u6, u7, u8, u9, u10;" ? Or
code for which "u1" and "u2" are variables, so that it would seem odd if
"u8" were a type? Or code for which the programmer had defined "u1" as
an alias for "bool", or had "u8" as an 8-bit bit-field in a struct?

I see your point, but I consider the risk to be quite low considering
it's in a separate namespace. Such issues would only arise if someone
does `using namespace std::ints;`.

> We have keywords like "return" and "class" rather that "rt" and
"cls", for good reasons. Overly long names for common uses are wrong
(no one would call Cobol a "readable" language!), as are overly short names.

> Using them for wide, global identifiers is a truly terrible idea.

This feature would be /opt-in/, in it's own namespace (not as global
identifiers, unless explicitly doing a "using namespace") and would not
be new keywords into the language.

Yes there are cases where short identifiers can be unclear in certain
contexts, but here it's not the case. These have already been widely
adopted, and their definitions are quite easy to understand (*i*32 -> 32
bit integer, *u*16 -> 16 bit unsigned integer). Also, this isn't the
first time single letters have been used in the STL for this, take for
example uint16_t, why not have it unsigned_int16_t? Or wchar_t, why not
have it be wide_char_t? It is a trade-off between brevity and verbosity,
and the opt-in namespace provides the user a choice.

I agree with Jan Schultke, in that this should be put on the shelves for
when _BitInt arrives, which would also add the additional semantic
meaning like Andre Kostur mentioned.

On 02.07.2025 13:31, David Brown wrote:
> On 01/07/2025 19:09, Radu Ungureanu via Std-Proposals 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.
>>
>
> Did you also look for the number of times identifiers like "u8" are
> used for other things, such as an 8-bit variable? "uint8_t u8 =
> 123;". Or for when the combination is used in connection with UTF-8
> ? Or someone has written "int u1, u2, u3, u4, u5, u6, u7, u8, u9,
> u10;" ? Or code for which "u1" and "u2" are variables, so that it
> would seem odd if "u8" were a type? Or code for which the programmer
> had defined "u1" as an alias for "bool", or had "u8" as an 8-bit
> bit-field in a struct?
>
>> > 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), 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.
>>
>
> Speaking as someone who uses the intN_t and uintN_t types almost
> exclusively in much of my code, which is for low-level small-systems
> embedded programming, I have absolutely no interest in such short-hand
> names. I think names like "u8" are the antithesis of clear coding
> practice, and are something to be discouraged, not made more common.
> I would not have a problem with "int32" or "uint8", but single-letter
> type names are /never/ a good idea. Single-letter identifiers, or
> single-letter plus number, are appropriate for very local use only -
> local variables in small scopes, parameter names for small functions,
> template parameters, etc. Using them for wide, global identifiers is
> a truly terrible idea.
>
> Yes, it is true that some newer languages use names like "u8". Doing
> so was IMHO a serious design fault. (Using size-specific types as
> their fundamentals, rather than implementation-dependent sizes like C
> and C++, is a reasonable choice - its the overly short names that are
> wrong.)
>
> We have keywords like "return" and "class" rather that "rt" and "cls",
> for good reasons. Overly long names for common uses are wrong (no one
> would call Cobol a "readable" language!), as are overly short names.
>
> David
>
>
>
>> 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
>>>
>>