On Sun, Sep 17, 2023 at 11:28 AM Barry Revzin via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Sep 15, 2023, 11:16 AM Jonathan Wakely via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> This works:
>> auto active_buttons = buttons | std::views::chunk_by([](auto& l, auto&
>> r){ return l.enabled == r.enabled; });
>> The problem here is not related to lack of support for projections, it's
>> that you need a binary predicate and &Button:enabled is not a binary
>> predicate.
>>
>
> Or, if you want the more convenient syntax, we dont need every algorithm
> to implement what is basically a function adapter:
> views::chunk_by(boost::hof::proj(&Button::enabled, std::equal_to()))
> prof(p, f)(x, y) does f(p(x), p(y))
>

It seems that if we had something like `boost::hof::proj` in the Standard
Library, then none of the C++20 Ranges algorithms would ever have needed
`Proj` parameters in the first place. E.g. instead of
    std::ranges::sort(vec, {}, &Button::size);
we could have written
    std::ranges::sort(vec, std::proj(std::less(), &Button::size));
Is there a good reason C++20 (or range-v3 in general) didn't adopt that
kind of solution? Is there something we can do with Ranges projections that
we couldn't have done with `hof::proj` composition, or vice versa?

–Arthur