On 12/10/24 5:55 PM, Andrey Semashev via Std-Proposals 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.
>
> 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.

Divisors are never zero. Should we introduce an integer type that
doesn't have representation of 0 so that programmers can't ever
accidentally divide by zero?

The problem isn't the range of representable values for a given type.
The problem is implicit promotions and conversions between types with
different value ranges.

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

We can't feasibly fix that in the core language (other than by providing
some kind of opt-in like new types, epochs, or profiles).

Tom.

>