[Bug libstdc++/111550] New: The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

[Bug libstdc++/111550] New: The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

[hewillk at gmail dot com]

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

            Bug ID: 111550
           Summary: The range adaptor closure object generated by
                    adaptor(args...) is not a perfect forwarding call
                    wrapper
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hewillk at gmail dot com
  Target Milestone: ---

The call operator of _Partial only handles the const& and && qualifiers, which
is missing the & and const&& and causes the following code to be rejected.

#include <ranges>

struct Five {
  operator int() &;
  operator int() && = delete;
};

int main() {
  auto take_five = std::views::take(Five{});
  auto r = take_five(std::views::iota(0));
}

https://godbolt.org/z/b19fsGceG

[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think all four bugs related to adaptor closures are very similar and could be
a single bug report.

[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

[hewillk at gmail dot com]

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

--- Comment #2 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> I think all four bugs related to adaptor closures are very similar and could
> be a single bug report.

Perhaps. Maybe I should collect them all. Sorry for bringing up bits and
pieces.

[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

[hewillk at gmail dot com]

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

--- Comment #3 from 康桓瑋 <hewillk at gmail dot com> ---
Let me report another issue I observed on this PR. 

According to [range.adaptor.object], adaptor(args...) uses
std​::​forward<decltype((args))>(args).. . to forward arguments into the call
wrapper's decayed member, whereas libstdc++ unconditionally uses std::moves,
which causes the following code to be rejected:

https://godbolt.org/z/EYoxzfWKn

  #include <ranges>

  struct NonMovable {
    NonMovable() = default;
    NonMovable(const NonMovable&) = default;
    NonMovable(NonMovable&&) = delete;
  };

  int main() {
    NonMovable nonmovable;
    auto r = std::views::take(nonmovable); // hard error in libc++ and
lidstdc++
  }

The libc++ implementation uses std::bind_back, so it will also produce a hard
error because std::bind_back requires that the argument must be
move-constructible.

It seems like only MSVC conforms to the standard's wording.

The standard does not require the type of args... here to be move-constructible
like other call wrapper factories (such as
std::bind_front/std::bind_back/std::bind) do, which seems to introduce some
inconsistencies.
Although I don't think such constraint is necessary, and I don't know if it's
worthy of an LWG?

[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

[ppalka at gcc dot gnu.org]

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

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The perfect forwarding issue is incidentally fixed in C++23 mode (when deducing
this is available) after r14-7150-gd2cb4693a0b383.

[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The comment #3 testcase seems fixed after r14-7218-gc48bedd1806722.