Types I am thinking of are that if one has for an unsigned word functions like in Tiago Freire's proposal https://isocpp.org/files/papers/P3161R4.html, one gets an implementation of the double word-sized types:
  double_unsigned<Word>
  double_signed<Word>
The templates can be easily overridden if assembler is available, and they also get the same functions as template half-word implementations are available.

So the process can be iterated to get uint128_t, uint256_t, …, and also signed types. They can be replaced with native types if available. One point of this iteration process is that the implementation does not require backwards jumps, making pipelining more effective.

Then one might have a bit-int variation bit_int<n, Word>, where also the underlying word is indicated.

This seems to be what you have. Perhaps it is necessary to have it in the implementation, so one would then lift it up into the standard.


> On 6 Sep 2025, at 00:53, Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> The implementor (i.e., the compiler vendor) chooses the alignment.
>
> For example, in clang19's header file avx512fintrin.h:
> typedef long long __m512i __attribute__((__vector_size__(64), __aligned__(64)));
>
> In gcc12:
> typedef long long __m512i __attribute__ ((__vector_size__ (64), __may_alias__));
> and they also have:
> typedef long long __m512i_u __attribute__ ((__vector_size__ (64), __may_alias__, __aligned__ (1)));
>
>
>
> -----Original message-----
> From: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Friday, September 5 2025, 3:28 pm
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> Cc: Tiago Freire <tmiguelf_at_[hidden]>
> Subject: Re: [std-proposals] D3666R0 Bit-precise integers
>
> But because the alignment of _BitInt is less strict an implementer must almost always assume that it is unaligned and implement the less efficient form of the algorithm.
>
> It would have been no different than providing uint64_t[8].
>
> So, in that sense it is identical to what we have right now.
>
> Nobody is saying that you couldn't write an algorithm to do it. It's just that it would be very inefficient to do so. The same way we could have not cared for the alignment of any type.
>
> But you would have been better of using a concrete type that signals to the compiler exactly what you want to do and have it guarantee you the right specs (size/alignment), and help it understand the type of operations you want to do.
>
> Using _BitInt would have been detrimental in that sense.
>