> On Dec 9, 2024, at 9:49 PM, Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Hi Rene, thanks. What's the threshold for "gratuitous"? There have
> been some notable breaking deprecations / removals in the past, though
> as mentioned certainly not as big as this would be.

An objective measurement would likely be along the lines of if there are APIs
that disagree about signedness of types, then the API change that causes
the least changes to existing code should be selected.

That said you introduced your proposal with "Signed and unsigned integers
do not mix well in C++”, but this proposal does not change that. Ignoring
all the potential issues that this change would cause, this change just moves
the burden onto authors of code that use unsigned types - e.g. it does not
remove the problem, just who experiences it. So it’s a huge change, and
does not actually remove or solve a problem.

> The deprecation + removal approach for signed here would break code
> under -Wsign-conversion -Werror but it wouldn't break anything else.

The above code would be broken, and “fixing” it requires inserting casts
to and from signed and unsigned representations, and making sure the
correct types are used so no truncation happens, every time you move
between the 30 year old APIs that have always been unsigned and all of
the other APIs you use they may not be able to change *ever*.

But then you have the code for which the change produces no warnings,
In those cases you can introduce a variety of security bugs as existing
bounds checks become wrong (negative values will now pass through
<size() bounds checks for example).

The ship sailed on the signedness of these types a long time ago, and if
you’re using them, you should be writing that code with unsigned types,
that also mitigates conversion difficulties.

Cheers,
  Oliver