Date: Tue, 10 Dec 2024 22:42:05 +0000
> 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.
No. Because in a distance between the beginning and the end, the beginning always comes before the end. You can do arithmetic with unsigned types, it's even more consistent than with signed types.
> 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. I have no idea where this "confusion" comes from. All of this is trivial to reason about, and it is pretty clear when you should use what.
For one I would think it would be far more productive to fix signed types to be more consistent, than to touch this.
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Thiago Macieira via Std-Proposals
Sent: Tuesday, December 10, 2024 11:26 PM
To: std-proposals_at_lists.isocpp.org
Cc: Thiago Macieira <thiago_at_macieira.org>
Subject: Re: [std-proposals] Signed sizes
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
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> 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.
No. Because in a distance between the beginning and the end, the beginning always comes before the end. You can do arithmetic with unsigned types, it's even more consistent than with signed types.
> 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. I have no idea where this "confusion" comes from. All of this is trivial to reason about, and it is pretty clear when you should use what.
For one I would think it would be far more productive to fix signed types to be more consistent, than to touch this.
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Thiago Macieira via Std-Proposals
Sent: Tuesday, December 10, 2024 11:26 PM
To: std-proposals_at_lists.isocpp.org
Cc: Thiago Macieira <thiago_at_macieira.org>
Subject: Re: [std-proposals] Signed sizes
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
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-12-10 22:42:08