On 26/11/2025 16:47, Thiago Macieira via Std-Proposals 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.
>
> 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.
>

I agree that _BitInt(128) /should/ be supported with exactly the same
way as a proposed new "int128_t" (however it may be called in the end),
or existing compiler extensions like __int128. (The same applies to
_BitInt(64) and int64_t, and _BitInt(8) and int8_t, and so on.)

How implementations /should/ behave, and how they /actually/ behave, is
not always the same thing. For an implementation that is new to _BitInt
and also new to int128_t, it is entirely conceivable that int128_t be
handled by specific treatment in the manner of other standard integer
types, while all _BitInt(N) types are handled by generic code for N
bits. That could mean _BitInt(N) types that could be handled more
efficiently, are handled correctly but inefficiently. We can hope that
such implementations will be few, or only temporary in nature, but they
are certainly a possibility.

It is also entirely plausible that some implementations will support
int128_t but not support _BitInt - again, that would hopefully only be a
temporary thing. Many current compilers support some kind of 128-bit
integer as an extension without having _BitInt support, so all they need
in order to support a standardised int128_t is a typedef in their
<cstdint> file.

I haven't checked the latest proposals for _BitInt in C++, but in C23,
an implementation does not need to support bit sizes beyond that of
"long long int" - that would still leave a need (or at least, a use) of
int128_t. Again, I hope that compilers choose to support larger _BitInt
types.

You could say that in a perfect world, a specific int128_t type is not
needed - but the C++ world is not perfect :-(

David