On Sat, 29 Mar 2025, 19:02 Frederick Virchanza Gotham via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> It's horrible when you use a "std::uint16_t" only to find that it
> promotes to a signed 32-Bit integer. Believe it or not, I recently
> wrote the following code:
>

Why?

On what platform in existence today does a type that's at least 32 bits
promote?

The "fast" integer types are pretty much a waste of time. If unsigned long
is acceptable for your code, why not just use that unconditionally?

Or why not unsigned int? If uint_fast32_t promotes then it must be lower
rank than int, so unsigned int would have greater rank than uint_fast32_t,
and support at least all the values that uint_fast32_t supports, and not
undergo promotion. Why is unsigned long preferable to unsigned int?







> using std::uint_fast32_t;
> // We can't use uint_fast32_t if it undergoes promotion,
> // so instead use long unsigned (which might be 64-Bit)
> typedef typename std::conditional<
> std::is_same< uint_fast32_t, decltype(uint_fast32_t() +
> uint_fast32_t()) >::value,
> uint_fast32_t,
> long unsigned >::type UIntType;
>
> So how about if we could tell the compiler that we want to use a
> specific integer type, and that we don't want it to promote. Perhaps
> here's how we'd define such an integer:
>
> short unsigned _NoPromo n = 0xFFFF;
>
> And similarly, if we already have a variable, and we want to do some
> calculations without it promoting at some point, then we make a
> _NoPromo reference to it:
>
> short unsigned original_variable = 0xFFFF;
>
> short unsigned _NoPromo &safe_variable = original_variable;
>
> safe_variable = ~safe_variable; // no promotion takes place here
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>