C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Member apply

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Mon, 3 Jul 2023 11:22:39 -0400
On Mon, Jul 3, 2023 at 11:15 AM Kang Hewill via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Dear experts,
>
> With the introduction of deducing this in C++23, variants in C++26 will have a member visit P2637R3, which is a great feature.
> I wonder, is it good to also add member apply to tuple-like objects? For example:
>
> auto sum = std::tuple{0, 'a'}.apply(std::plus{});
> auto dist = ranges::subrange{...}.apply([](auto i, auto s) { return s - i; });
>
> Is this consistency superfluous, or does it have some value? One benefit I can think of is that this enables us to write the form of
>
> tuple.apply(...).apply(...).apply(...).apply(...)
>
> which may be an enhancement. What do you think?
>
> Hewill

I think the reasoning for `std::apply` being a non-member function is
very different from that of `visit`. `std::visit` *only* works with
`std::variant`, so it makes sense for it to be a member function. In
contrast, `std::apply` works with any type conforming to the
`std::tuple`-style of access.

That doesn't mean that `tuple` cannot or shouldn't have a member
`apply` function (though the possibility of
`tuple.apply(...).apply(...).apply(...).apply(...)` is a good reason
not to). But the non-member `apply` would still be preferred in
generic scenarios.

Received on 2023-07-03 15:22:52