> On Dec 11, 2024, at 7:14 PM, Jeremy Rifkin <rifkin.jer@gmail.com> 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@apple.com> wrote:
>>
>>
>>
>>> On Dec 9, 2024, at 10:46 PM, Oliver Hunt <oliver@apple.com> wrote:
>>>
>>>
>>>
>>>> On Dec 9, 2024, at 9:49 PM, Jeremy Rifkin via Std-Proposals <std-proposals@lists.isocpp.org> 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