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
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
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.
or
template
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.
but, whatever.
In Christ, Steven Watanabe