https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100577
--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> --- Some context: the purpose of this deleted operator() is so that when invoking an adaptor object as an rvalue, we don't ever select the const&-qualified operator() overload, because doing so would break the perfect forwarding call wrapper semantics required of partially applied adaptor objects and pipelines, and cause us to silently accept the P2281 example 'x | views::split(non_view_range)' (forming a split_view containing a dangling reference). This deleted const&&-qualified overload always wins over the const&-qualified overload in the rvalue case, and so prevents this breakage from happening. This PR arguably calls for an improvement on the frontend side -- the diagnostic for when overload resolution chooses a deleted function could also perhaps explain why the other candidates weren't selected. But I think we can also work around this deficiency on the library side by essentially disabling the perfect forwarding call wrapper machinery for range adaptors that don't need it, which currently is all of them except for views::split. For the other adaptors, we could get away with just a single overload for _Partial::operator() and _Pipe::operator().
