On 04/09/2025 07:48, Peter C++ via Std-Proposals wrote:
> FWIW
>
> one can implement efficient non-UB integer replacement types, eg, for
> safety critical systems using enum class types as representation.
>
> see for example: https://github.com/PeterSommerlad/PSsimplesafeint
> <https://github.com/PeterSommerlad/PSsimplesafeint>
>
> Regards
> Peter
>

You can indeed make such classes - and give them dangerously misleading
names like "Simple Safe Int".

It is fine to implement wrapping signed integer classes if that's what
you want - it is /not/ fine to pretend they are somehow safe or suitable
for safety-critical systems. It doesn't matter if your overflows wrap -
if you have an overflow, your safety-critical system is screwed.

(Some other aspects of your library /are/ positive for safety, such as
disallowing mixed signed operations and limiting certain other
operations. It's only the overflow behaviour I am in strong
disagreement about.)


You'd be a lot better off with :

 using SignificantlySaferIntType = int64_t;

That would eliminate the vast majority of signed integer overflow bugs,
and give the /correct/ answer to 32-bit overflows.

And anyone writing new code with enough care about overflow and code
correctness that they might consider something beyond just using "int",
will already be able to handle overflow in various ways - such as
sanitizing values before calculations ("look before you leap", rather
than trying to find a way to recover from jumping off a cliff and
somehow ending up miles in the air). The checked arithmetic functions
in C++26 are another option.




I am in favour of integer class libraries that handle overflow in
different ways. But the naming should be based on what is actually done
- undefined behaviour, wrapping, zeroing, throwing, trapping, calling
terminate/abort/whatever, saturating, returning an unspecified but valid
value, setting errno, etc.


I am not in favour of pretending or implying that the use of a
particular integer class makes the code "safe" (or even just "safer").