> On Dec 9, 2024, at 10:46 PM, Oliver Hunt <oliver_at_[hidden]> wrote:
>
>
>
>> 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.

As this thread is _still_ going with numerous arguments for or against signed and unsigned I think that shows that signed vs unsigned is not a case with an objectively superior choice, and given the magnitude of this change it would need a much stronger justification.

I want to be clear, I am not arguing “unsigned is better than signed” or vice versa, just saying that the *value* of the change is clearly not universally - or overwhelmingly - agreed upon, and changes of this magnitude would really require that.

Of course as your proposal notes mixing signedness is miserable on footgun filled in C and C++, so new APIs continue to use unsigned types so that they can interact cleanly with the existing APIs.

So whether or not we think it’s the best choice now, we’re somewhat stuck with the misery for the foreseeable future.

—Oliver