On 16 February 2026 11:16:31 UTC, Bo Persson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>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?
>
>
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Fast in the standard usually implies the former case: for fast computations
Same as std::(u)int_fastN_t :P

I aim to standardise these 2 type categorises to make the accessible for everyone
For instance when we want a 24bit colour, we can just say std::make_uleast<24> and we get an integer that's at least wide enough to hold 24 bits of data (for instance a 32-bit integer on x86, just an example)

Cheers,
Tymi.