On Thu, Jul 3, 2025 at 12:21 AM 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.

`std::move` is pretty different though. If you *know* what needs to
happen in `std::move`, then it's easy to write. But I suspect that way
more people use `std::move` than would be able to replicate it without
looking up how.

> - It’s worth standardizing so that it is standard. What if one project calls it i8 but another calls it s8?

Why is that a problem? Neither name is "correct", so it's unclear what
problem would be caused by calling it something you didn't expect. If
one project decided to call it something you didn't recognize, you'd
still have to look up what it meant.

This is begging the question. The notion of standardizing it to make
it a standard presupposes that it *deseves* to be a standard. And that
was the question under discussion.

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

This presupposes that one considers them to be "more sensible names."
If you just see them as "alternate names", then you'd need a footnote
regardless since they're not standard.

And if these names are supposedly so common that everyone uses them
(ie: the main argument for standardizing them), why would you need a
footnote to describe what everyone already knows?

Ultimately, I really don't like setting a precedent that C++ should
typedef its fundamental types to adhere to the behavior of other
languages. `std::uint8_t` may be more verbose than `u8`, but there is
no room for misunderstanding.