Date: Mon, 7 Jul 2025 08:42:10 +0200
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
> 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
Received on 2025-07-07 06:42:20