Le 18/03/2017 à 23:08, Peter Dimov via Boost a écrit :
Vicente J. Botet Escriba wrote:
* do we want (can) to use as (HOMF) high-order meta-functions? if we nedd them at all). IIUC, Peter library doesn't works with HOMFs. * do we want a Hana style with "concepts" and with customizations? Do we want other data type than type lists? IIUC Peter's library works only with template aliases as data types and almost variadic class template with type parameters is a good candidate for a type list (even std::variant :( )
These two are the distinguishing features of mp11. All other libraries have chosen differently. To clarify, the mp11 approach does support higher-order metaprogramming, but it chooses to make the ordinary case easier at the expense of the HOMF case, which is made harder, whereas the other libraries choose to make HOMF easier, at the expense of taking quoted metafunctions as arguments, which requires aliases to be quoted.
mp11, in contrast, requires quoted metafunctions to be de-quoted (Q::invoke) when passed to algorithms.
I have the impression that mp11 cannot use the meta function returned by
a function as a parameter of an algorithm, but I'm missing something
that it should be evident to you. How can we define a compose
meta-function that could be used later as parameter?
algo
To clarify further, std::variant
is absolutely a supported typelist in mp11. If you have a std::variant V, you can remove the duplicate types from it with mp_unique<V>. This is again a deliberate design decision which keeps simple uses simple at the expense of making more complicated uses more complicated. With the other libraries, to remove the duplicates from a variant, you first have to convert it to the native typelist type, apply 'unique', then convert back to std::variant.
I know. I just find it weird to take std::variant as a data type that models type list. I agree with you that given the definition you have used in mp11 (it is also the case of Brigand), std::variant models a mp11 type list. I'm not saying that it is not useful and I suspect that it should reduce the compile time. My main concern is that Boost.Hana has more data types than type list and that the algorithms are associated to concepts. IIUC, mp11 has only one concept (variadic template) and all the algorithms we can define on this very rich data structure. Maybe you are right and this is all we need. At a first glance I would prefer a meta library that is based on the design of Hana. I'm not saying here that I want the mixity of type and values. Of course, if the compile times are very different I could change my first impression. Vicente