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
>>
>