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@lists.isocpp.org> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Tuesday, December 10, 2024 9:22 PM
To: std-proposals@lists.isocpp.org
Cc: Sebastian Wittmeier <wittmeier@projectalpha.org>
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@lists.isocpp.org>
Gesendet: Di 10.12.2024 21:16
Betreff: Re: [std-proposals] Signed sizes
An: std-proposals@lists.isocpp.org;
CC: Olaf van der Spek <ml@vdspek.org>;
On Tue, Dec 10, 2024 at 5:01 AM Jeremy Rifkin via Std-Proposals
<std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals