Why is C++20's `std::popcount` restricted to unsigned types?

The functions from P0553R4: Bit operations are constrained to only work on unsigned integers. The proposal does not give a reason for this constraint. I can see that this makes sense if the bit representation of a signed integer is not defined, but with C++20, we are guaranteed that signed integers use two's complement.

To me, it thus seems reasonable to allow e.g. std::popcount to be called with a signed integer type, as an implementation could simply cast to the corresponding unsigned type to do the bit-operation in the unsigned domain.

What is the reason for P0553R4 to add this constraint? (Is it simply missing synchronization between P0553R4 and P0907R4?)

Pretty simple: Implicit widening conversions on unsigned types do not change the result. Implicit widening conversions on signed types (including promotions) perform sign-extension, which does change the result if the input was negative.

Having an operation whose result becomes incorrect due to integer promotion definitely falls into the "foot cannon" category.

You can still feed (bit patterns representing) negative values to popcount, but you have to take control of the conversion sequence, which helps you get the result you expect.

popcount counts bits, and hence takes a type intended for use as a "bit container".

• unsigned integer types are intended for use as bit containers (or modulo-2^n values).
• signed integer types are intended for use as numbers, somewhat more abstractly.

Yes, it's true that since C++20, twos-complement semantics are guaranteed for signed integers, but that's a non-essential detail - which is exactly why two's-complement wasn't guaranteed until C++20. And if you're not a language-lawyer, you are likely to not even be aware of this change.

So, instead of trying to be a language-lawyer/human encyclopedia - make less assumptions about the exact semantics of types which may have been defined otherwise. If you make such assumptions - you might luck out and popcount correctly; but you might just get bitten by @BenVoigt's answer.

_{See also the application of the same principle in my answer to this question.}

The reason why popcount in C++20 is restricted to unsigned types is to ensure consistent behavior and avoid potential pitfalls when working with signed integers.

When applying bitwise operations, such as counting the number of set bits (popcount), on signed integers, there can be unexpected behavior due to the sign bit. The sign bit can propagate during operations, potentially leading to incorrect results or undefined behavior.

To ensure consistent and predictable behavior, the decision was made to restrict popcount to unsigned types. Unsigned integer types are intended for use as bit containers, while signed integer types are intended for use as numbers. By restricting popcount to unsigned types, it avoids potential pitfalls and ensures that the function behaves as expected in all cases.