Re: [boost] [range][algorithms] How about making the range algorithms pipeable as the range adaptors are?

Subject: Re: [boost] [range][algorithms] How about making the range algorithms pipeable as the range adaptors are?
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2013-09-19 16:17:01

On Thu, Sep 19, 2013 at 6:03 PM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> On 19-09-2013 18:17, Viktor Sehr wrote:
>
>> It would be syntactically really nice if the stl-algorithms wrapped in
>> boost range were pipeable, as with the adaptors, making it seamless to
>> combine them in left-to-right statements
>>
>> For non-mutating algorithms I think it's an obvious evolvement
>> const auto& max_pos = some_range | filtered(..) | max_element;
>> const auto& num_elements = some_range | filtered(..) | count(42);
>>
>> ...instead of inside out as it is now
>> const auto& max_pos = max_element(some_range | filtered(..));
>> const auto& num_elements = count(some_range | filtered(..), 42);
>>
>>
>
> The pipe syntax usually just change the iterator type. If we want
> to chain algorithms in a facy way, I think a new syntax should be used
> to minimize confusion between the two concepts. Say
>
>
>   const auto& max_pos = some_range | filtered(..) >> max_element
>
> could have been nice. But then we run into precedence problems.
> Maybe >>= would do.
>
>
IMHO the pipe syntax should just be a shorthand for (left associative)
function application, i.e.:

    x | f

should simply be a equivalent to

    f(x)

This way there would be no fear of confusing concepts and it would be of
more general application and would interact in a powerful way with partial
application (i.e. bind).

I think that $ would be the haskell equivalent.

-- gpd