On 2026-02-16 at 12:40, Tymi via Std-Proposals wrote:
> 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?
>
>
>
> Fast in the standard usually implies the former case: for fast computations
> Same as std::(u)int_fastN_t :P
>

Where does it say that? I cannot find any wording about what "fast"
means here.