On Sun, Aug 23, 2026, 11:12 Jan Schultke via Liaison <
liaison_at_[hidden]> wrote:

>
>
> On Sun, 23 Aug 2026 at 08:45, Nevin Liber via Liaison <
> liaison_at_[hidden]> wrote:
>
>>
>>
>> On Sun, Aug 23, 2026 at 12:25 AM Jan Schultke via Liaison <
>> liaison_at_[hidden]> wrote:
>>
>>> When working on a draft of P4444 std::big_int (
>>> https://isocpp.org/files/papers/D4444R0.html#std::uint_multiprecision_t),
>>> we've stumbled upon the problem that C++ does not yet have a "word type"
>>> that would be suitable as the "limb type" for multiprecision.
>>>
>>
>> Given that big int libraries have existed for a while, why is there a
>> pressing need now?
>>
>
> There is no "pressing need" in terms of timing. It's simply something
> people have tried to standardize as early as 2004 because it has
> always been and will always be immensely useful. The paper's motivation
> section goes into great detail as to why std::big_int should be in the
> standard.
>
>
>>
>>
>>> That is, the largest possible unsigned integer type that has native
>>> arithmetic support.
>>>
>>
>> What keeps this from suffering the same problems as intmax_t; i.e., once
>> baked into ABIs it is effectively impossible to change when the underlying
>> hardware does.
>>
>
> "When the underlying hardware does" is a pretty unlikely scenario, and I'm
> not sure if it has ever happened in the history of computing in a way that
> would change a std::uint_maxfast_t type. This would require providing new
> arithmetic instructions with greater width, on an existing architecture,
> without creating a new ABI. For example, it would happen when providing
> 128-bit arithmetic support on x86_64. Usually, that doesn't happen, and the
> historic jumps from 32-bit to 64-bit came with completely new ABIs.
>

It's foolish to try to predict what's the hardware will be like in 10+
years.

The fact is, people in the 80s probably didn't consider 128 bits integers.
And there are implementations that stores big ints in chunk of 128. So
enshrining size_t might be a mistake on day one.

What's to say that we won't get instructions for 256 bits arithmetic in the
future? etc

in general, the fast, max, etc aliases were short sighted.

>
> The issue with std::intmax_t has always been much simpler and dumber, up
> until C23 fixed it. You could not add a new __int128 extended integer
> type as an implementation without also changing std::intmax_t.
> std::intmax_t would force you into an ABI break even if nothing about the
> hardware changed.
>
>
>> I'm thus interested in standardizing a type alias in <stdint.h> that has
>>> the size. In P4444, we call that uint_multiprecision_t, but that's perhaps
>>> not universal enough. Names like "uint_maxfast_t" or "uint_word_t" come to
>>> mind.
>>>
>>
>> I was never really enamoured with the int_fast*N*_t types, since they
>> don't guarantee, well, anything other than being at least *N* bits
>> wide. This doesn't seem any different, because "fast" isn't clearly
>> defined.
>>
>
> It is different. The wording we have in
> https://isocpp.org/files/papers/D4444R0.html#big%2eint%2esyn recommends
> it "should be chosen to have the greatest possible width so that an
> arithmetic expression ([expr.pre]) performed on operands of the type
> corresponds to a single instruction in the execution environment."
>
> That's a lot more specific than "fast".
>

not really.

>
>
>
>> What are your thoughts?
>>
>>
>> That we are re-inventing int, badly. The original *int*ention of int
>> was that it be the "fastest" type on the target, whatever that means.
>>
>
> Yeah well, that original intention was lost 20 years ago or something. I
> think the idea of int being the native integer type was always destined
> to fail because it's clunky to leave a hole in the standard integer types,
> where short is 16-bit and int is 64-bit. Or perhaps, short would be
> 32-bit, leaving no 16-bit type. It would have also made long and long long
> basically useless on 64-bit and sparked a 64-bit dialect of C++ where
> people use int only, avoiding any of these wider types.
>
> On 128-bit architectures like RV128, it would have become even more
> comical, with short presumably still being 16-bit and int, long, and long
> long all being 128-bit.
>
> You would inevitably need to patch the holes in the standard integers with
> extended integer types or add more standard integer types, and neither
> seems like a desirable outcome.
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2026/08/1691.php
>