Boost logo

Boost :

Subject: Re: [boost] Yap's formal review is starting now!
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2018-02-16 20:28:39


On Fri, Feb 16, 2018 at 2:05 PM, Steven Watanabe via Boost <
boost_at_[hidden]> wrote:

> AMDG
>
> On 02/16/2018 11:29 AM, Peter Dimov via Boost wrote:
> > Steven Watanabe wrote:
> >
> >> > As is, it isn't, because MSVC 2017 can't even include hana.hpp at >
> >> present, let alone make any use of it.
> >>
> >> It took me about 5 minutes to fix that.
> >
> > The implied argument being that it's better to fix Hana, or at least
> > those parts of it that Yap uses, to compile under MSVC instead?
> >
>
> Yes. After working around the decltype()::value problem, I
> just had to add /permissive- to get (at least some of)
> Hana's tests to build with msvc. Yap itself has more
> problems on msvc than Hana does. (I gave up after seeing
> it ICE in the SFINAE for tag transforms.)
>
> > I still don't think it's better to have the user write
> >
> > template <typename Expr1, typename Expr2, typename Expr3>
> > decltype(auto) transform_expression (
> > boost::yap::expression<
> > boost::yap::expr_kind::plus,
> > boost::hana::tuple<
> > boost::yap::expression<
> > boost::yap::expr_kind::multiplies,
> > boost::hana::tuple<
> > Expr1,
> > Expr2
> > >
> > >,
> > Expr3
> > >
> > > const & expr
> > )
> >
> > instead of
> >
> > template <typename Expr1, typename Expr2, typename Expr3>
> > decltype(auto) transform_expression (
> > boost::yap::expression<
> > boost::yap::expr_kind::plus,
> > std::tuple<
> > boost::yap::expression<
> > boost::yap::expr_kind::multiplies,
> > std::tuple<
> > Expr1,
> > Expr2
> > >
> > >,
> > Expr3
> > >
> > > const & expr
> > )
> >
>
> Between these first two, I don't actually care.
>

Same here.

> > or
> >
> > template <typename Expr1, typename Expr2, typename Expr3>
> > decltype(auto) transform_expression (
> > boost::yap::expression<
> > boost::yap::expr_kind::plus,
> > boost::yap::expression<
> > boost::yap::expr_kind::multiplies,
> > Expr1,
> > Expr2
> > >,
> > Expr3
> > > const & expr
> > )
> >
>
> This is a bit nicer in this case, but it's also a
> bit of a trade-off as the requirements are more difficult
> to state clearly. Saying it must be exactly a
> (hana|std)::tuple is completely unambiguous. Also,
> doing nested matching like this is somewhat imperfect
> as it doesn't handle expr_refs transparently.
>

Right.

There's a larger point here, though. I'm preparing a library for
submission to Boost. It works on at least one compiler, which is our
(admittedly very loose) standard for submissions. It also is using other
Boost libraries to avoid reproducing the work done in those. This is also
fine for a Boost library to do, even expected. If you don't want new
library authors to use existing Boost libraries, we need a clear rationale
for when and why that's wrong.

All the concerns about MSVC support boil down to how many people could use
the library on its first day as part of Boost. Even if I were to make it
work for MSVC 2017, how many more users does that cover? It seems only to
cover the live-at-head folks. If MSVC continues to get better language
support, how long does that support cover those folks before the compiler
is good enough anyway? My time for that support is not a good trade for me
personally. If someone else wants to navigate MSVC's limitations and
submit patches, I'll switch over to std::tuple in the interface, and
maintain that work.

If that does not happen (and it probably won't), then we know for a fact
that using Yap on MSVC does not matter enough for anyone to actually do the
work to make that happen. If so, what exactly is this discussion about?

Zach


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk