[...]
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::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
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.
