> Or, just use the existing types.

This is purely ergonomic, uint16_t is a lot more work to type and integer
types are typed often.

Longer more cumbersome names disincentivize their use even though consensus
seems to be that fixed-width integer types are better all around (see most
prominent C++ style guides, why rust mandates these, etc).

Anecdotally, I have a keyboard that allows me to make a dedicated “_” key
on the home row and even then I find myself wishing it was easier to type.

Cheers,
Jeremy

On Thu, Jul 3, 2025 at 00:07 Andre Kostur <andre_at_[hidden]> wrote:

> On Wed, Jul 2, 2025 at 9:21 PM Jeremy Rifkin via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > > Is it then worth standardising? Anyone can write the 8 lines of "using"
> > statements.
> >
> > While this is true, I can think of at least two reasons it should be
> standardized:
> > - It’s worth standardizing so a user doesn’t have to write the
> boilerplate in some utils.hpp or common.hpp file in all projects. std::move
> is similarly trivial to write yourself, etc.
>
> Or, just use the existing types.
>
> > - It’s worth standardizing so that it is standard. What if one project
> calls it i8 but another calls it s8? Furthermore, code examples online
> should be able to use these more sensible names without having to add a
> footnote along the lines of “assume the convention of these 8 usings is
> followed”
>
> Or they use the existing and perfectly sensible names of int8_t or
> uint8_t. Afraid that I'm not seeing the benefits of the shorter
> names. And I work in the networking space where almost everything is
> a fixed bit-width type.
>