On Wednesday 11 December 2024 05:31:07 Brasilia Standard Time Tiago Freire via
Std-Proposals wrote:
> Well, it does only if you reject negative values. Make it unsigned, and you
> don’t need to reject negative values because unsigned values cannot be
> negative. That’s the point.

But you still need to reject the positive values that correspond to those
negative ones. They would by construction always be larger than the
container's size, so a single bounds check is necessary everywhere except in
resizing operations. For the resizing operations, you can also the check and
let the memory allocation fail, but strictly speaking containers should not
rely on it.

As for whether compilers replace a
  s >= 0 && s < size
with
  u < unsigned(size)
is a QoI issue.

> Case in point Qt is a good example of an API that uses signed indexing, and
> it’s a very large pain point (for me) because it doesn’t match well with
> the things you want to use the containers for, introducing failure modes
> and pain points that simply do not exist with the standard containers
> precisely because unsigned is and should be the right type for indexes.

And the point the OP made is that you must use signed for distances, therefore
you will have different types for different things. Instead of having a single
set of rules for "all the numbers in a container", we have two.

> Signed integers also overflow, except it is UB in the standard, which makes
> it an argument against using signed values, not for.

Or an argument for using them, because they don't overflow, and thus have been
shown time and again to benefit from some compiler optimisations. There's a
reason why proposals to remove this particular UB keep being rejected.

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