[libcxx][ranges] adds concept `sized_range` and cleans up `ranges::size`

[cjdb]

Summary

• adds sized_range and conformance tests
• moves disable_sized_range into namespace std::ranges
• removes explicit type parameter

Implements part of P0896 'The One Ranges Proposal'.

[zoecarver]

LGTM.

libcxx/include/__ranges/concepts.h

14

How was this working before?

libcxx/test/std/ranges/range.req/range.sized/sized_range.compile.pass.cpp

24

Rvalue array?

[cjdb]

libcxx/include/__ranges/concepts.h

14

🤷

libcxx/test/std/ranges/range.req/range.sized/sized_range.compile.pass.cpp

24

That's int[5].

[Quuxplusone]

libcxx/test/std/ranges/range.req/range.sized/sized_range.compile.pass.cpp

24

I assume Zoe was asking for xvalue (rvalue-reference) to array: int (&&)[5] and int (&&)[].

libcxx/test/std/strings/string.view/range_concept_conformance.compile.pass.cpp

31–32

Unrelated to this PR, but it strikes me as odd that string_view is not a std::ranges::view.
Should you perhaps be asserting stdr::view<std::string_view&> instead?

[cjdb]

libcxx/test/std/ranges/range.req/range.sized/sized_range.compile.pass.cpp

24

This test checks that an lvalue array is a sized range and that an rvalue array is too. I'm not sure what adding a test to check an rvalue reference to an array is going to add overall that int[5] doesn't already do.

libcxx/test/std/strings/string.view/range_concept_conformance.compile.pass.cpp

31–32

That would be because we haven't enabled string_view as a view yet.

[zoecarver]

libcxx/test/std/strings/string.view/range_concept_conformance.compile.pass.cpp

31–32

Hmm. I think we should at least have a comment saying that this test is wrong. I'd even say we should comment out the static_assert too (and make it positive).

[Mordante]

LGTM!

libcxx/include/__ranges/concepts.h

9–10

Not part of your changes, but can you use a triple underscore? _LIBCPP_RANGES_CONCEPTS_H -> _LIBCPP___RANGES_CONCEPTS_H

libcxx/test/std/ranges/range.req/range.sized/sized_range.compile.pass.cpp

50

Why is this the only one to check stdr::range?

[Quuxplusone]

libcxx/test/std/strings/string.view/range_concept_conformance.compile.pass.cpp

31–32

@zoecarver: If we comment out the assert, we'll have to set some kind of watchdog to remind us to comment it back in, in the PR that enables string_view-as-a-view. Which will definitely fail to remind us, and then tech debt.
By keeping this "wrong" assert enabled, it serves as a regression test: it serves as its own infallible watchdog. When string_view becomes a view, buildkite will point directly at this test file, telling us that we need to flip the sense of the assert as part of the same PR. That's excellent. (And also excellent to see in the git history later, when we're wondering which commit caused string_view to become a view.)
I wouldn't mind seeing a // TODO: string_view is nonconforming comment at the end of this line, though.

A possible alternative approach (but I assume we won't block D102434 on this): first land a PR that makes string_view-a-view; then land this PR with the assert already passing.

[cjdb]

libcxx/include/__ranges/concepts.h

9–10

Will do.

14

Oh, because of transitive includes.

libcxx/test/std/ranges/range.req/range.sized/sized_range.compile.pass.cpp

50

Confirming it's a range, but not a sized range.

libcxx/test/std/strings/string.view/range_concept_conformance.compile.pass.cpp

31–32

@zoecarver: If we comment out the assert, we'll have to set some kind of watchdog to remind us to comment it back in, in the PR that enables string_view-as-a-view. Which will definitely fail to remind us, and then tech debt.
By keeping this "wrong" assert enabled, it serves as a regression test: it serves as its own infallible watchdog. When string_view becomes a view, buildkite will point directly at this test file, telling us that we need to flip the sense of the assert as part of the same PR. That's excellent. (And also excellent to see in the git history later, when we're wondering which commit caused string_view to become a view.)

+1

I wouldn't mind seeing a // TODO: string_view is nonconforming comment at the end of this line, though.

A possible alternative approach (but I assume we won't block D102434 on this): first land a PR that makes string_view-a-view; then land this PR with the assert already passing.

Sure, I can add that TODO before merging (it won't appear on Phab though).