On Wed, Oct 8, 2025 at 11:23 AM Yexuan Xiao via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Why is it allowed to return a signed integer? C++ users are accustomed to the fact that the size_type of containers is an unsigned integer, so the size of containers should also return an unsigned integer. sizes that return negative numbers are pathological and cannot be used. The current specification forces writers of generic algorithms to convert the result to unsigned on every call to ranges::size, which is something ranges::size should have taken care of. If they don't do this, the compiler will complain about signed and unsigned mismatches.

Can you give an example of where that would happen? Presumably, the
range's size_type should be used consistently. Incrementing iterators
or using `operator[]` ought to use the same type as the return value
of `size`. So as long as the writer of the generic code is writing it
correctly, this shouldn't be a problem.

That is, writers of generic code should use the type that gets
returned, and use it consistently.

> C++20 also added ranges::ssize, which always returns a signed integer. If generic algorithms prefer signed integers, they can use ranges::ssize. Therefore, it makes no sense for `ranges::size` to preserve the signedness of the return type of containers' size. Does C++ need ranges::usize? I believe the answer is clearly no. If C++ doesn't fix ranges::size in a timely manner, perhaps one day users will invent ranges::usize themselves and then tell others not to use ranges::size.

Is there any evidence that this is likely? Besides your personal
experience with it, is this a wide-spread concern?