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.