[Bug libstdc++/104465] New: std::vector<std::string> should satisfy std::ranges::viewable_range (P2415 for -c++2b)

["zyn7109 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104465

            Bug ID: 104465
           Summary: std::vector<std::string> should satisfy
                    std::ranges::viewable_range (P2415 for -c++2b)
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zyn7109 at gmail dot com
  Target Milestone: ---

Given the following code,

```cpp
#include <iostream>
#include <ranges>
#include <string>
#include <vector>

int foo(std::ranges::viewable_range auto) { return 1; } // #1
int foo(auto) { return 0; }  // #2

int main() {
  const std::vector<std::string> v {"1", "2", "3", "4"};
  std::cout << foo(v) << " ";
  for (auto vv: v | std::views::reverse) std::cout << vv << " ";   // #3
}
```

compiling with GCC 12.0.1 (20220208)
(https://wandbox.org/permlink/aPZzDSVF0wbtUQF8), the output is "0 4 3 2 1"
rather than "1 4 3 2 1" since the overload resolution selects #2 for `foo`.
However, as P2415 was merged into C++23
(https://github.com/cplusplus/papers/issues/1085), `std::vector<std::string>`
is now a `viewable_range` and with Clang 15, "1 4 3 2 1" is the result.
(https://wandbox.org/permlink/8uzBa0Ot6Yj22Z0l).

It seems that P2415 is still not implemented for libstdc++ yet. However, GCC
accepts #3 since range was introduced from GCC 10.x (I'm not quite sure which
version) while considering
`std::ranges::viewable_range<std::vector<std::string>> == false`. As the
cppreference (https://en.cppreference.com/w/cpp/ranges/reverse_view) or C++20
draft suggests (24.7.1 [range.adaptor.object]/1,
https://timsong-cpp.github.io/cppwp/n4861/range.adaptors#range.adaptor.object-1),
the range adaptor `std::views::reverse` only takes `viewable_range` as
arguments. So it makes me confused and I wonder if I missed something.

Clang 13 rejects the above code (https://gcc.godbolt.org/z/xoKesEz7q), which is
as expected.