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.

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?

Not that it's going to happen and std::span is an indication that not even new
things can be considered Green Field enough to be allowed this innovation.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering