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@lists.isocpp.org>
Gesendet: Mi 29.03.2023 12:19
Betreff: Re: [std-proposals] Slow bulky integer types (128-bit)
An: std-proposals <std-proposals@lists.isocpp.org>;
CC: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>;
On Wed, Mar 29, 2023 at 11:07 AM Jonathan Wakely <cxx@kayari.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals