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

Subject: Re: [boost] Yap's formal review is starting now!
From: paul (pfultz2_at_[hidden])
Date: 2018-02-16 17:41:33

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.