[Bug c++/95100] New: <ranges> xxx_view adaptors don't work with pipeline operator

[Bug c++/95100] New: <ranges> xxx_view adaptors don't work with pipeline operator

[rhalbersma at gmail dot com]

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

            Bug ID: 95100
           Summary: <ranges> xxx_view adaptors don't work with pipeline
                    operator
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rhalbersma at gmail dot com
  Target Milestone: ---

Combining the std::ranges::xxx_view adaptors with the pipeline operator does
not compile, in contrast to the supposedly expression equivalent
std::ranges:views::xxx 

#include <iostream>
#include <ranges> 
#include <vector>

int main() {
    auto v = std::vector { 1, 2, 3, 4, 5, 6 };

    // OK
    for (auto elem : std::ranges::views::reverse(v)) {
        std::cout << elem << ',';
    }

    // OK    
    for (auto elem : std::ranges::reverse_view(v)) {
        std::cout << elem << ',';
    }

    // OK
    for (auto elem : v | std::ranges::views::reverse) {
        std::cout << elem << ',';
    }

    // error: missing template arguments before ')' token
    for (auto elem : v | std::ranges::reverse_view) {
        std::cout << elem << ',';
    }

    // OK
    for (auto elem : v | std::ranges::views::transform([](auto e) { return e +
1; })) {
        std::cout << elem << ',';
    }    

    // error: class template argument deduction failed:
    for (auto elem : v | std::ranges::transform_view([](auto e) { return e + 1;
})) {
        std::cout << elem << ',';
    }
}

See online example on Wandbox here:
https://wandbox.org/permlink/E6ScFmm8DdmkFo74

Tested this also for drop_view, take_view, filter_view etc., with similar
results (not shown for brevity in the code snippet).

[Bug c++/95100] <ranges> xxx_view adaptors don't work with pipeline operator

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to rhalbersma from comment #0)
> Combining the std::ranges::xxx_view adaptors with the pipeline operator does
> not compile, in contrast to the supposedly expression equivalent
> std::ranges:views::xxx 

Hmm, I don't see anything in the spec that would imply views::xxx should be
expression-equivalent to xxx_view.  What I see is that views::xxx(E) is, for
some values of E, expression-equivalent to xxx_view{E}.

For instance [range.reverse.overview] says:

   Given a subexpression E, the expression views​::​reverse(E) is
expression-equivalent to: 
   [...]
   - Otherwise, equivalent to reverse_­view{E}.

Could you point me to the relevant bits of the spec that would imply this
stronger expression-equivalence?

[Bug c++/95100] <ranges> xxx_view adaptors don't work with pipeline operator

[rhalbersma at gmail dot com]

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

--- Comment #2 from rhalbersma <rhalbersma at gmail dot com> ---
OK, so the rewriting rules [range.adaptors]/4, that make views::xxx(R)
equivalent to R | views::xxx, do not allow to rewrite the expression equivalent
xxx_view{R} as R | xxx_view? That would be rather finicky, perhaps even a
defect in the Standard?

[Bug c++/95100] <ranges> xxx_view adaptors don't work with pipeline operator

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
No, it's not a rewriting rule. It says that the library implementation needs to
give range adaptor objects an overloaded operator| that allows them to be used
that way.

There's no magical rewriting going on, just operator overloading. You can't
overload an operator to take a class template as an argument.

Class templates are not objects and objects are not class templates.

Not a bug and not a defect.