> Typing underscores
> is not harder than any one of the dozens of punctuation marks, or
> capital letters.

Ideally you shouldn't have to type any of those for types like these that
are used all the time.

Cheers,
Jeremy

On Mon, Jul 7, 2025 at 1:42 AM David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 06/07/2025 18:11, Simon Schröder via Std-Proposals wrote:
> > I only see one good reason to introduce an additional alias: fixing some
> of the drawbacks of current behavior, 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.
> >
>
> I don't buy the "difficult to type" argument at all. When you are
> writing code, most of the time is spent thinking, reading, and figuring
> out what to write. The vision some people have of typing in code at
> high speed is from unrealistic movies, not reality. Typing underscores
> is not harder than any one of the dozens of punctuation marks, or
> capital letters. And on many international keyboard layouts, such as
> the Norwegian one I use, some of the punctuation keys are "dead" keys -
> to get "~", I need to use Alt-Gr plus the "[{" key on US/UK layouts,
> then press space or another key (but not one for an accented letter,
> like ñ, õ, etc.). Does this hinder my coding? Not in the slightest -
> at least not in a measurable way. Those with Greek, Bulgarian or
> Ukrainian keyboard layouts also seem to manage fine, despite layouts for
> a completely different alphabet.
>
> And note that for many coding styles, underscores are already a regular
> component of a fair proportion of user identifiers.
>
> It's fair to dislike code with a high number of punctuation marks due to
> the cognitive effort involved - that's a solid argument against
> "uint<8>" or similar. But the physical effort of typing "_t" is totally
> overwhelmed by the cognitive convenience of the clear type indicator.
>
> > Is _BitInt solving automatic narrowing or just integer promotion?
> >
> > Probably, automatic narrowing could also be fixed by profiles. Then,
> this point is moot.
> >
>
> Yes. It can also be solved by compiler warnings (though it would be
> nice to have it standardised).
>
> > 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. 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). But,
> it would also be cumbersome to type having to alternate using shift for
> every single keystroke.
> >
>
> Having a template called "u" is worse than identifiers like "u8" -
> remember, templates are identifiers too, and clash in the same way.
> Hugely better would be "uint<8>" or "uint_t<8>", although there the "_t"
> suffix is redundant.
>
> > 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.
>
> People took an unbelievably long time to get used to using uintN_t types
> in C and C++. Many people still don't use them appropriately.
> Introducing a second incompatible set of "standard" aliases would just
> send the message that C++ has /no/ standard fixed size integer types -
> it just offers a couple of pre-defined alternatives for those that don't
> want to invent their own. That is not a helpful signal.
>
> > (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!
>
> It would be vastly better to have "safety profiles" or common warnings
> on narrowing.
>
> Anyway, we already have that for uint8_t and friends :
>
> uint8_t x = 1234; // Warning on any sane compiler
> uint8_t x { 1234 }; // Error for narrowing conversion
>
> Those who don't use either of these to stop narrowing initialisations
> are not going to move to "u8" to stop narrowing initialisations - at
> most, they will move to "u8" for laziness.
>
> David
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>