On Fri, Feb 16, 2018 at 2:05 PM, Steven Watanabe via Boost < boost@lists.boost.org> 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
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.
Same here.
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.
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