On 2023-03-29 at 13:35, Sebastian Wittmeier via Std-Proposals wrote:
> 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.

We now also have "integer-class type", which behaves as an integer, but
is still none of the other two categories.

http://eel.is/c++draft/iterator.concept.winc#2

Another way to be "not an extension" but also not be "the widest integer
type".

Perhaps we need pretty_large_t and but_not_too_large_t? :-)


>
> -----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
>
>