An unsigned type would not help at all, as they have to wrap around and a < a + 1 is not necessarily true for unsigned types (they only guarantee: a >= 0 && a + 1 >= 0). So signed types are the recommended type for loops in most cases. If one wants to make sure that a value is always positive or in some other range, one needs pre- and post-conditions and possibly test for them. Neither using signed nor using unsigned types prevent overflows or underflows or loss of precision for FP types. And in most programs it is not acceptable to get wrong arithmetic results, so making those UB conditions returning defined garbage instead (with lower performance) would not really help in those cases.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 28.04.2023 12:42 Betreff:Re: [std-proposals] Reduce undefined behavior of signed integer literal arithmetic operations An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Fri, Apr 28, 2023 at 8:42 AM Bo Persson via Std-Proposals <std-proposals_at_[hidden]> wrote: > > > If that's the only reason why signed overflow is UB, > > It's not. > > No wrap around also lets the compiler assume that a < a + 1 is always > true. Useful for loop conditions. Well then let's make an exhaustive list of all the reasons why signed overflow is UB. I've already proposed a solution to the 'double negative' problem, i.e. -(-INT_MIN) == INT_MIN With regard to "a < a + 1" being always true, well then in the future it can sometimes be negative. If you don't want this to happen then I think you're using the wrong tool. I do realise that a massive proportion of C++ programmers use a signed integer type when an unsigned would be adequate, but individual programmers will just have to iron out their own bad habits. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals