On Sun, 6 Jul 2025, 17:12 Simon Schröder via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I only see one good reason to introduce an additional alias: fixing some
> of the drawbacks of current behavior,


Then it would be a new type, not an alias.


i.e. automatic narrowing (and maybe widening) of integers. One minor reason
> would be that typing the underscore in int32_t is a little bit cumbersome
> on a QWERTY keyboard layout.
>
> Is _BitInt solving automatic narrowing or just integer promotion?
>
> Probably, automatic narrowing could also be fixed by profiles. Then, this
> point is moot.
>
> In any case, if we were to introduce a new shorthand “keyword” for these
> special integer types those would need to be in a global scope and not
> hidden in a namespace. I believe that the OP’s research has already shown
> we shouldn’t name them u8, and so on. We could use the suffix _t, but it
> would be really ridiculous (when we already have uint8_t). To address my
> minor point about typing the underscore we could name them u8t.


That might be least favourite of all the names so far.


This might have a better chance of avoiding global name clashes. Or maybe
> u<8>. It makes it clear that it is a type (because of the template
> parameter).


Except for all the other types of templates.


But, it would also be cumbersome to type having to alternate using shift
> for every single keystroke.
>
> I see less of a problem with u8 having to know it is a type. People will
> get used to it quickly if it is standardized. (And most people also have
> highlighting in an IDE to tell them it is a type.) There is precedent that
> C++ uses unusual naming to avoid name clashes (like nullptr, co_yield). So,
> we could use u8t instead.
>
> And how would we teach when to use u8 (or u8t or whatever naming we use)
> instead of uint8_t? That’s easy if u8 behaves differently than regular ints
> (no narrowing): Always use u8! It’s the better int!
>