> On 26 Nov 2025, at 16:47, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Wednesday, 26 November 2025 01:16:27 Pacific Standard Time David Brown via
> Std-Proposals wrote:
>> (It is also entirely reasonable to suppose that specific
>> 128-bit integers might be supported more efficiently than arbitrary
>> sized _BitInt types.)
>
> int128_t should be supported exactly as efficiently as _BitInt(128), no faster
> and no slower, because it should *be exactly the same support*. Different
> types, but since it's exactly the same size and behaviour, it should be using
> the exact same implementation. Like long with either int or long long. Yes,
> this is a QoI, but it's an easy fix for a compiler to specifically detect that
> the _BitInt has the same size as another integer it already supports, one I
> expect all compilers to do and also one I expect users to request if not.

There are special ways to optimize for powers of 2 and also the square of a modulus, so it might be prudent to add support for uint<2^2^n>_t for some suitable n, perhaps up to uint4096_t or something. If the type is not available natively, it is possible to make a recursive template implementation that encourages pipelining—I have done so for division, which is the hard part.

> Other _BitInt sizes, including smaller ones, could have worse performance.
> It's up to the user to determine a size that meets their needs and achieves
> the performance they require.

Even though C++ bit_int<k> types could specialize to such implementations, I suspect they will typically use a multiple-word implementation, perhaps derived from the C implementation which does not have such templates.