There are cases when I find mpl::eval_if much easier to use than mp11::mp_eval_if, mp11::mp_if, mp11::mp_cond and mp11::mp_defer. For example, converting something like this to Boost.MP11 is rather painful if one wants to preserve lazy evaluation of all eval_if branches in the tree. One particular pain point is that mp_defer does not compose with anything that takes template template parameters, including mp_eval_if and mp_defer itself.
It would be helpful if Boost.MP11 provided a direct equivalent of mpl::eval_if. Specifically, a metafunction that would lazily instantiate each of the branches depending on the condition, where the branches implement the ::type protocol. In general, I think the library could use a better support for the ::type protocol.
There are cases when I find
mpl::eval_ifmuch easier to use thanmp11::mp_eval_if,mp11::mp_if,mp11::mp_condandmp11::mp_defer. For example, converting something like this to Boost.MP11 is rather painful if one wants to preserve lazy evaluation of alleval_ifbranches in the tree. One particular pain point is thatmp_deferdoes not compose with anything that takes template template parameters, includingmp_eval_ifandmp_deferitself.It would be helpful if Boost.MP11 provided a direct equivalent of
mpl::eval_if. Specifically, a metafunction that would lazily instantiate each of the branches depending on the condition, where the branches implement the::typeprotocol. In general, I think the library could use a better support for the::typeprotocol.