Boost logo

Boost :

Subject: Re: [boost] Yap's formal review is starting now!
From: P F (pfultz2_at_[hidden])
Date: 2018-02-16 05:19:32

> On Feb 15, 2018, at 6:55 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> Zach Laine wrote:
>> > The interface is not more complicated at all. The user just puts an > std::tuple where he'd have put the hana::tuple. The implementation is > more complicated. :-)
>> Well, mostly, but it's still user-visible. A transform might pattern match against expressions like this:
>> struct my_xform {
>> template<typename TerminalValue1, typename TerminalValue2>
>> auto operator()(
>> plus_tag,
>> my_expr<expr_kind::terminal, TUPLE<TerminalValue1>> const & lhs,
>> my_expr<expr_kind::terminal, TUPLE<TerminalValue2>> const & rhs)
>> { return /*...*/; }
>> };
>> If TUPLE can be only std::tuple or hana::tuple, that's a lot easier to write than if it can be any TupleLike.
> That's true in the case where the authors of `my_xform` and `my_expr` are different. If the same person has written both, he would know what tuple to use.
> But yes.
> It's also true that for any nontrivial manipulation you'd need tuple algorithms, which std::tuple doesn't have, as your get_arity example demonstrates. And yet, tying to Hana doesn't feel right.
> I'm thinking about properly completing the "tuple" part of mp11 with all the algorithms that make sense, starting with `transform`, but I doubt I'll have time for that in any near future.

You can use Boost.HOF(aka Fit) for that. It should be fine for small tuple sizes:

for_each(tup, f) => unpack(proj(f))(tup)
transform(tup, f) => unpack(proj(f, construct<std::tuple>()))(tup)
fold(tup, f) => unpack(fold(f))(tup)
concat(tup1, tup2) => unpack(construct<std::tuple>())(tup1, tup2)

It is a little more to write, but it is fairly trivial vs implementing it yourself.

Boost list run by bdawes at, gregod at, cpdaniel at, john at