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?