On Tue, 10 Dec 2024, 22:55 Andrey Semashev via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> 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.
>


Always? I've definitely used iter[-1] when dealing with random access
iterators and with pointers into arrays. It's more concise than
*std::prev(iter), especially if other code nearby is using iter[0] and
iter[1].




> I think using signed integers for sizes and offsets is wrong because
> those values are never negative.


Sometimes they are.


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
>