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