> I think the thread is no longer useful as it has regressed to people
angrily arguing in favor of their preferred viewpoint, and at times I feel
somewhat unprofessional/abusive language at each other.

+1

> I have no idea how such a fundamental change to the language would ever
be possible

To clarify, I don’t have in mind a new fundamental type but rather a
library type with appropriate conversions and comparisons. I am not sure if
this is what Bjarne and others had in mind or not. I have to give more
thought as to whether a library type cold achieve this sufficiently instead
of fundamental language changes.

Cheers,
Jeremy


On Wed, Dec 11, 2024 at 22:32 Oliver Hunt <oliver_at_[hidden]> wrote:

>
>
> > On Dec 11, 2024, at 7:14 PM, Jeremy Rifkin <rifkin.jer_at_[hidden]> wrote:
> >
> > 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.
>
> I think the thread is no longer useful as it has regressed to people
> angrily arguing in favor of their preferred viewpoint, and at times I feel
> somewhat unprofessional/abusive language at each other.
>
> >
> > 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.
>
> I have no idea how such a fundamental change to the language would ever be
> possible, the real problem that C++ has is the inherited implicit
> conversion between the two meaning there’s decades of code that depends on
> it, which leads to the intermingling. “Modern” languages were to start with
> no existing code and make consistent choices (rust chose unsigned, swift
> chose signed, javascript chose double :D
>
> But yeah, I think we’re stuck with our collective misery for now :-/
>
> —Oliver
>
> >
> > 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
>
>