Re: [boost] Yap's formal review is starting now!

Subject: Re: [boost] Yap's formal review is starting now!
From: Peter Dimov (lists_at_[hidden])
Date: 2018-02-16 00:55:32

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.