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
>