Integer promotion, like overload resolution and name lookup, is a minefield. But unlike those other notions, it's actually really easy to experiment with making your own integer-like types "in userspace."  I strongly suggest that Frederick make a prototype of his desired integer-like type as a class type with overloaded operators, and actually use it for a while, to find out where the remaining trouble spots are. Many of these trouble spots will be unforeseen and unpredicted by even the cleverest thinker; they'll have to be found by experience. Also, moving this type's implementation into the standard library will not magically fix those trouble spots.
Having done that, the questions to be answered by the proposal are no longer
- What semantics do I actually want, concretely? and
- Are those semantics implementable? and
- Am I right that I actually want those semantics, or do they just create new problems for me that I didn't foresee?
Instead, the question becomes
- Now that I have a library solution to my problem, is it worth putting in the standard? or should I just publish my code on GitHub and call it a day?
is related.

my $.02,

On Fri, Mar 31, 2023 at 10:12 AM Giuseppe D'Angelo via Std-Proposals <> wrote:
On 31/03/2023 13:47, Frederick Virchanza Gotham via Std-Proposals wrote:
> So I wonder would it be good to have another set of integer types that
> don't promote?

Would it be too far fetched to generalize this, and propose a fully
policy-based integer type, with individual policies to decide:

- the bit width
- if it is signed or unsigned
- whether overflow/underflow is UB, or wrap around, or saturate
- if it takes part in integer promotions or not
- if it implicitly converts towards any other integer types, or forbids
narrowing, or doesn't implicitly convert at all
- etc.

My 2 c,
Giuseppe D'Angelo
Std-Proposals mailing list