Hi Frederick,   on common architectures __uint128_t is not a fundamental type according to the standard: https://eel.is/c++draft/basic.fundamental#def:integer_type   Paragraph 11 defines integral types and integer types as a subset of the fundamental types: https://eel.is/c++draft/basic.fundamental#11   One can argue about the terms and whether they make more sense in one or the other way, but that is how they are used nowadays, and that probably won't change. One could also save a single very long (mathemtical) integer in a 1 Mibit long memory array. One could provide a class for it with arithmetic operators. Mathematically it is an integer, but it is not a fundamental type. It cannot be stored in registers, the CPU ALU cannot handle the word size, memory accesses are not atomic, ... (I am not saying that all those criteria are true for all fundamental integral types, but they are definitely not true for the 1 MiBit integer). You can find a discussion about __int128 here: https://quuxplusone.github.io/blog/2019/02/28/is-int128-integral/   Hope that helps to give some meaning for the currently used terms, Sebastian   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.03.2023 11:21 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 10:01 AM Jonathan Wakely <cxx_at_[hidden]> wrote: > >> It doesn't matter if you're from another planet, or if your first >> language isn't English, the type '__uint128_t' is an integer type. If >> the C++ Standard, or if any given C++ compiler, doesn't recognise it >> as an integer type, then that's a totally different issue. > > > Then take the discussion somewhere else, this list is about the C++ standard. The point I'm making is relevant. > By definition, there are no integral types wider than uintmax_t, so if __int128 is wider than uintmax_t, it's not an integral type. Every once in a while I'm reminded that I have my own personal variety on the human condition, and that there are sane rational people in the world who form totally different views than I do when presented with the same evidence. You and I see the world differently, and that's okay. So maybe let's try to find a middle ground. Are you saying that the C++ Standard's definition of 'integer' (or 'integral') is different from how a computer scientist or a mathematician would understand it? Do we really want the C++ Standard to redefine English language scientific terms? __uint128_t is a type. I think we agree on this point. __uint128_t holds an integer. I think we also agree on this second point. __uint128_t is an integer type. This seems to be where we disagree. There isn't anything about the standard of any programming language that makes __uint128_t any more or any less of an integer type. Now if you want to say that the C++ Standard has a finite list of types that it considers to fall into the category of "integer types", and if you're saying that __uint128_t isn't on that list, then that just doesn't makes sense. It would only make sense if one of the two following actions were taken: (1) The C++ Standard gives a definition of 'integer/integral' contrary to how the term is understood by computer scientists and mathematicians (2) The C++ Standard uses a term other than 'integer/integral' to denote these types Things start getting a bit hairy when you allow the redefining of simple English words. Back when I was a teenager, the word 'cash' meant money in the form of coins and paper, but it seems nowadays 'cash' means any money that is readily accessible. Of course human languages evolve over time; the English bible from the 1600's uses some words in some really strange ways, and the meaning of a term creeps as the years and decades go by -- but there isn't any stretch of the imagination by which __uint128_t isn't a type that holds an integer (i.e.an integer type). -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals