On Fri, 2018-02-16 at 08:39 -0700, Steven Watanabe via Boost wrote:
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.)
User most likely want to use hana, but they can't since they need to support MSVC or gcc 5. Zach has seemed to show an interest in maintaining a MSVC or C++11 version if it were contributed, but I dont see how that is possible with Hana in the interface. Any such contribution would break API compatibility or would require maintaining two API which seems worse.