Boost logo

Boost :

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

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.

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