Date: Wed, 11 Dec 2024 01:55:27 +0300
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.
> 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.
Received on 2024-12-10 22:55:31