Hi Olvier,

> 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.

The thread is still going and has gone so fast I've lost track and
haven't been able to reply to most.

I don't necessarily want to try to convince people that signed is
superior enough to warrant a massive change like this.

Bjarne's paper mentions the idea of a unicorn type that would just do
the right thing when working with signed / unsigned. There aren't a
lot of details in the paper or committee notes on what shape this
would take and I'll need to give it more thought myself. If something
along those lines can be made to work, this is probably the only way
to feasibly pursue improvements here without introducing breakage and
a large-scale adoption burden.

Cheers,
Jeremy



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