AMDG On 02/16/2018 06:41 AM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
On 02/15/2018 05:55 PM, Peter Dimov via Boost wrote:
<snip> 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.
What's the point of making libraries if you refuse to use them?
Who is "you" in this sentence?
This wasn't a rhetorical question.
There are three levels at which Hana can be used:
1. hana::tuple in the interface of Yap, resp. in the specification and tests 2. In the implementation of Yap 3. In user code based on Yap (f.ex. implementing transforms)
For which level do you object to a supposed refusal to use Hana?
I'm going to split (1): 1a. Users passing tuples to Yap should not be restricted to hana::tuple. 1b. On the other hand, it's completely reasonable for Yap to give hana::tuple to users. (Yap has to choose something, after all) I think that Yap is closer to 1b than 1a. (I definitely object to (2) and as for (3), well, if users don't want to use hana, it's their loss.)
Because I was talking about #1.
The thing is, in most cases, the tuple type is chosen by Yap, not by the user. Most of the time, users don't actually need to care what the tuple type is, either. template<expr_kind K, class Tuple> struct my_expr { static const expr_kind kind = K; Tuple elements; }; struct a_transform { template<class T> auto operator()(terminal_tag, T&&t); // ... }; Consequently, I think it's fine for Yap to use whatever is most convenient. For the record, if Zach wants to use std::tuple everywhere instead, I think that's also fine. In Christ, Steven Watanabe