Date: Tue, 17 Feb 2026 09:22:59 +0000
On 16 February 2026 14:12:20 UTC, Bjorn Reese via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On 2/16/26 14:41, Jan Schultke via Std-Proposals wrote:
>
>> Maybe once we have _BitInt, we could add std::bit_int_unpadded_tand std::bit_int_fast_ttraits that give you the next larger _BitIntwithout padding, and the next larger _BitIntthat is "fast".
>
>Or the proposed type traits can be extended with _BitInt once it is
>landed.
>
>I would rename the type traits to be more consistent with existing
>type traits though
>
> make_least<N> -> make_signed_least<N>
> make_uleast<N> -> make_unsigned_least<N>
>
That's a much better name for it. I thought it would be a little verbose, but I suppose that's a non-issue.
>> I'm not so sure we want such traits for the standard integer types.
>
>Such traits are useful when doing integer computation without overflow,
>where you want to use a wider integer type for the computation. Promoted
>integer types already does this implicitly, and the traits just make
>that an explicit choice. This enables generic integer computation code
>that also works with std::simd types.
>
That, and also for anything else that requires an arbitrary bit integer. These traits give out an unpadded integral type that's at least N bits in width. I can definitely see myself using it instead of least_t/fast_t types we already have.
For instance colours.
Cheers,
Tymi.
>On 2/16/26 14:41, Jan Schultke via Std-Proposals wrote:
>
>> Maybe once we have _BitInt, we could add std::bit_int_unpadded_tand std::bit_int_fast_ttraits that give you the next larger _BitIntwithout padding, and the next larger _BitIntthat is "fast".
>
>Or the proposed type traits can be extended with _BitInt once it is
>landed.
>
>I would rename the type traits to be more consistent with existing
>type traits though
>
> make_least<N> -> make_signed_least<N>
> make_uleast<N> -> make_unsigned_least<N>
>
That's a much better name for it. I thought it would be a little verbose, but I suppose that's a non-issue.
>> I'm not so sure we want such traits for the standard integer types.
>
>Such traits are useful when doing integer computation without overflow,
>where you want to use a wider integer type for the computation. Promoted
>integer types already does this implicitly, and the traits just make
>that an explicit choice. This enables generic integer computation code
>that also works with std::simd types.
>
That, and also for anything else that requires an arbitrary bit integer. These traits give out an unpadded integral type that's at least N bits in width. I can definitely see myself using it instead of least_t/fast_t types we already have.
For instance colours.
Cheers,
Tymi.
Received on 2026-02-17 09:23:02
