evaluation of constraints for std::ranges::views::drop() fails unnecessarily

[avikivity]

Bugzilla Link	47509
Version	trunk
OS	Linux
CC	@JohelEGP,@mmatrosov,@craffael,@zygoloid,@viccie30,@jwakely

Extended Description

The test program

==== begin test program ====

#include <vector>
#include <ranges>

void f(std::vector<int> vec) {
    for (auto& e : vec | std::ranges::views::drop(1)) {
    }
}

==== end test program ====

Does not compile on clang, either with libc++ or libstdc++, failing on some enormously complicated constraints. gcc accepts it.

[avikivity]

I narrowed it down to eager evaluation of constraints:

1. view_interface<iota_view> is instantiated as a base class of iota_view. Clearly iota_view isn't defined at this stage, it's just a forward-declared name.

2. view_interface instantiates iterator_t, which is an alias to std::__detail::__range_iter_t.

3. __range_iter_t instantiates __ranges_begin.

4. __ranges_begin requires that its template parameter is a __member_begin<> (among other options, but this is the valid one here).

5. __member_begin requires that the type (iota_view) have a begin() function. But the type isn't defined yet.

According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97120#c1, evaluation should be lazy.

[llvmbot]

This reduces to something interesting:

Clang accepts:

template <typename _Tp>
concept __member_begin = requires(_Tp __t) {
    {__t.begin()};
};
template <typename _Tp>
concept nothing = requires(_Tp __t) {
    {42};
};
template <typename _Tp>
requires __member_begin<_Tp> void __ranges_begin() {}
template <typename _Derived>
struct view_interface {
    void foo() requires __member_begin<_Derived> {}
//    void bar() requires nothing<decltype(__ranges_begin<_Derived>())> {}
};
struct drop_view : public view_interface<drop_view> {};

---

Uncomment the declaration of bar and clang rejects this. gcc is OK with both.

If I understand it correctly, both gcc and clang agree that the direct use of a unsatisfied requires should just disable foo. The disagreement is about an indirect one, like in bar(). With gcc bar() is just disabled, but clang produces an error. Note that gcc rejects:

---

template <typename _Tp>
concept __member_begin = requires(_Tp __t) {
    {__t.begin()};
};
template <typename _Tp>
concept nothing = requires(_Tp __t) {
    {42};
};
template <typename _Tp>
requires __member_begin<_Tp> void __ranges_begin() {}
template <typename _Derived>
struct view_interface {
    void foo() requires __member_begin<_Derived> {}
    void bar() requires nothing<decltype(__ranges_begin<_Derived>())> {}
};
struct drop_view : public view_interface<drop_view> {
    void zed() {
        this->bar();
    }
};

---

[mmatrosov]

This is indeed clang's bug: #50208

[jwakely]

This is indeed clang's bug: llvm/llvm-bugzilla-archive#50864

And this one and that are both dups of #44178

[Craffael]

mentioned in issue #48855

[ldionne]

This doesn't happen anymore, see https://godbolt.org/z/5fhnM3YTo.

Also, on libc++, we haven't implemented views::drop yet (I have a patch locally and I need to finish it up) so this fails as expected. But the Clang bug seems to be gone.

[avikivity]

It does not compile with clang trunk: https://godbolt.org/z/Prn9Kze64

[ldionne]

Oh yes, you are right, sorry about that.

https://godbolt.org/z/hsvoWM3je shows:

Clang trunk / libstdc++: fails
GCC trunk / libstdc++: works
Clang trunk / libc++: fails because libc++ doesn't implement it yet

[jwakely]

And this one and that are both dups of Bug 44833

Which is now #44178

[Quuxplusone]

Duplicate of #44178.