[...]
Indeed there is something one can't do with Hana and that is exactly the very most important use case for Metal: control template overload resolution through SFINAE.
Consider the following very simple toy example.
~~~ #include <boost/hana.hpp> namespace hana = boost::hana;
template <typename X> constexpr auto fun(X const& x) -> decltype(void(hana::reverse(x)), true) { return true; }
constexpr bool fun(...) { return false; }
static_assert(fun(hana::tuple_t<>), ""); static_assert(!fun(0), ""); ~~~
[...]
To be fair, though, you can do this: ~~~ template<typename X, typename = std::enable_if_t<hana::Sequence<X>::value>> constexpr auto fun(X const& x) { return true; } ~~~ Here, `Sequence` is the concept required to have `hana::reverse`. In concept world, assuming a concept-ified Hana, you would write something like this instead: ~~~ template<hana::Sequence X> constexpr auto fun(X const& x) { return true; } constexpr auto fun(...) { return false; } ~~~ Also, I personally don't see the benefit of this SFINAE friendliness all the way down. In fact, I usually think that using a library that does that is more difficult, because when you mess up you don't get any information of why you messed up 20 instantiations down the stack. Instead, you just get a SFINAE failure at the top of the stack, with some back trace that may or may not be helpful to determine the cause of the initial failure. In any case, I do think that Metal (and Brigand) are useful libraries and Boost probably has room for one of those. I just don't think _this_ is the reason why. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/metal-Feature-Complete-Request-for-Feedba... Sent from the Boost - Dev mailing list archive at Nabble.com.