Or we just do literally nothing.
Just get used regular unsigned integers, because there’s absolutely nothing wrong with them and the standard already is how it should be in this matter.

From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Tuesday, December 10, 2024 9:22 PM
To: std-proposals_at_[hidden]
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] Signed sizes


Or arithmetic types with compile-time or runtime upper and lower boundaries (a fixed interval of values) with contracts support?

-----Ursprüngliche Nachricht-----
Von: Olaf van der Spek via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Gesendet: Di 10.12.2024 21:16
Betreff: Re: [std-proposals] Signed sizes
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Olaf van der Spek <ml_at_[hidden]<mailto:ml_at_vdspek.org>>;
On Tue, Dec 10, 2024 at 5:01 AM Jeremy Rifkin via Std-Proposals
<std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
> In the specific case of std::views::enumerate, one option would be to
> add a variation that produces unsigned indexes. This, plasters over
> the underlying issue and could lead ot more confusion about mixing,
> however, it would alleviate some issues.
>
> The other option would be a bigger plan to deprecate and remove
> unsigned indexing APIs and replace them with signed APIs:

A third option would be to introduce one or more new types.
For example unsigned types with a bit less and without modulo
semantics, such that they can always convert to signed types. This
would allow you to mix and match these with signed types without
issues.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals