On 16 February 2026 13:00:18 UTC, Jan Schultke <janschultke_at_[hidden]> wrote:
>If the goal is portability, then _BitInt (P3666) is the way to go.
>_BitInt(N) is exactly N bits large, possibly by inserting padding.
>
>Once we have that, I would seriously question the purpose of std::make_least
>and std::make_fast aliases that yield some implementation-defined type.
>These traits are somewhat insuited for generic code anyway because for some
>widths, you get a type that is promoted to int. It's hard to write generic
>code for any N because of these differences, and outside of generics, you
>can just use std::uint_fast32_t et al. directly.
>
>On Mon, 16 Feb 2026 at 11:09, Tymi via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>> When trying to get the smallest integral type of N bits, we either have to
>> ensure N is one of 8, 16, 32 or 64, or trust the implementation to have a
>> least/fast type for our width, which is often not the case.
>>
>> That's why I propose a way to standardise making least width integers and
>> fast size integers within the library:
>>
>> A sample interface
>> std::make_least<N> => a signed integer with at least N bits in width
>> std::make_fast<N> => a signed integer with at least N bits in width that's
>> also the fastest size for the given width
>> std::make_uleast<N> => an unsigned integer with at least N bits in width
>> std::make_ufast<N> => an unsigned integer with at least N bits in width
>> that's also the fastest size for the given width
>>
>> I'm only concerned about signed/unsigned, but that's ultimately the
>> interface design and can/should be changed.
>> Cheers,
>> Tymi.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>

I don't want exact-width types. I want an integral type that's at least N bits in width, which currently std::(u)int_leastN_t cannot provide for all widths. _BitInt is an interesting idea, however, does it work with arbitrary sizes and produces an integral type with at least N bits in width?
Does it also have a fast version for heavy computational data?

I want to further standardise these 2 cases.
Cheers,
Tymi.