The standard already defines - as you suggested -  two categories: standard integer types and extended integer types. It could really make sense to introduce - as you called it - `uintmax_oversize_t` -, or better named `uintmax_extended_t` to cover both stand and extended types.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.03.2023 12:19 Betreff:Re: [std-proposals] Slow bulky integer types (128-bit) An:std-proposals <std-proposals_at_[hidden]>; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Wed, Mar 29, 2023 at 11:07 AM Jonathan Wakely <cxx_at_[hidden]> wrote: > > No. The English term still means the same thing. The standard defines terms > **using English words** but within the scope of the C++ standard, they have > the meaning ascribed to them by the standard. The standard defines what > "argument" means. That doesn't mean I can't have an argument with clowns > on the internet, it just means that **within the scope of C++** that word has a > specific meaning, as defined by the standard. At the beginning of a written contract, or on the first few pages of a protocol specification, there are precise definitions given for some of the terms that will be used later in the document. This isn't out of the ordinary. These precise definitions are based on the simple meaning of the English word, but are more specific to the topic being discussed. If I were to read the specification of the POP3 email protocol, and if it were to read: * recipient = the person sending the email * sender = the person receiving the email This would be rather strange. I mean the document can define terms however it wants, but there should be some sense in how the terms are based on the simple English words. If the C++ Standard wants to separate integer types into two categories, for example 'compact integer types' and 'oversized integer types', then that's fine, I would like that distinction, because then we could have 'uintmax_t' and 'uintmax_oversize_t'. However if we're just going to say that some integer types are not really integer types then that doesn't make sense. It's extremely counter-intuitive for is_integral_v to be false for __uint128_t. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals