The basic question is whether unsigned types should be used at all for signifying that numbers can only be positive or zero.   As far as IMHO I and some others understand them, unsigned types should be used for binary data and logical operations and signed types should be used for arithmetic.   For the three reasons    - the behavior at overflow,  - preventing mixing signed and unsigned and  - the valid range seldom is 0..UINT_MAX, more often the valid range is limited from above and sometimes even from below, e.g. no 0.  - And even if the valid range is positive and zero, unsigned arithmetic explicitly allows going below 0 (and doing a wrap-around), so a compiler should not even create a warning with maximum safety levels/profiles on.   -----Ursprüngliche Nachricht----- Von:Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 10.12.2024 23:55 Betreff:Re: [std-proposals] Signed sizes An:std-proposals_at_[hidden]; CC:Andrey Semashev <andrey.semashev_at_[hidden]>; On 12/11/24 01:25, Thiago Macieira via Std-Proposals wrote: > On Tuesday 10 December 2024 14:50:42 Brasilia Standard Time Tiago Freire via > Std-Proposals wrote: >>> Except where it isn't and negative indices have a "count from the end" >>> meaning or an API can return a negative value to indicate "item not >>> found". Whether that is good API or not we can debate, but those API >>> exist. >> I’ve never stated that there aren’t any libraries with an API that works >> like that. It is a matter of fact that they do exists Qt being one of them, >> and it is also a matter of fact that there are many libraries who are >> ill-formed, it is not a productive discussion to have. Whether or not those >> API’s are good (and specifically how the C++ standard has handled it), is >> on the other hand the whole point. And while I would even agree that signed >> indexing is appropriate in situations where you can index from a middle >> point (including backwards or forwards), this is not the case of the >> indexable standard containers, nor it is what is being argued. > > Then I raise a different and more relevant case than negative indices: > distances. All of the iterator and pointer arithmetic must result in distances > and those must be signed. The size of a container is nothing but the distance > from the beginning to the end and the index of an element is the distance from > the beginning to that element. Negative distances only take place when you want to move an iterator backwards. In every other use case, including sizes and indexes, you're always talking non-negative integers. I think using signed integers for sizes and offsets is wrong because those values are never negative. Signed types simply mis-document the interface and confuse the users. And then frustrates the users if they want to fix the issue in their end. > Therefore, whether the library has signed indices/sizes or has uses for signed > indices, it must deal with signed distances and therefore must have some > signed API. And therefore the OP's point remains: since we must deal with > signed anyway, shouldn't we solve the mix/match by removing the unsigneds? No, the fix is to resolve problems of poor interaction between signed and unsigned integers in the language. And the OP doesn't propose that. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals