On 2026-02-16 at 11:09, Tymi via Std-Proposals 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.

Before adding more "fast" types to the standard, we ought to define *what* should be fast.

If you do many computations on a small number of values, that might be faster if you make the variables the "natural" size of the system (int?).

If you store large arrays of such values, it might be more efficient to have them compact to reduce cache effects.

Which "fast" should the standard prefer?