Joaquin M López Muñoz wrote:
1.1 I really don't like the mp_ prefix. I understand this is meant to minimize clashes when using namespace::mp11, but the same purpose can be served by simply using namespace mp=boost::mp11.
Well... it's also meant to make it possible to move mp11 into std without changes. :-)
1.3 I find that these metafunctions are missing/misplaced: pop_back
pop_back is not provided for the same reason std::vector doesn't provide pop_front - it's much less efficient than its siblings, and providing it could mislead people into thinking that it's equally efficient.
at/at_c (should be in list.hpp) insert/insert_c/erase/erase_c (should be in list.hpp) replace_at/replace_at_c
The partitioning is roughly based on whether the operation can be trivially
expressed (f.ex. mp_second
clear (should be in list.hpp)
mp_clear could be in list, yes.
1.5 Treatment of sets and maps is very dissimilar. Why mp_map_find but no mp_set_find? Why mp_set_push_(back|front) but no mp_map_push_(back|front)? Why mp_map_erase but no mp_set_erase? I think both interfaces should have the same functions, except possibly mp_map_(replace|update).
Set operations are only provided for the cases where the generic list-based algorithm would be unsuitable or less efficient.
Porting from / coexisting with Boost.MPL would be greatly aided by some utility function to convert Boost.MPL sequences to Mp11 lists:
... This unfortunately doesn't work in general - as Bruno Dutra explained to me - because MPL operations on, f.ex. mpl::vector, do not necessarily return an mpl::vector.
1.7.1 Why there's no eval_if_q_c (or eval_if_c_q?)
The purpose of the _q forms is twofold; one, to enable passing a quoted metafunction, and two, to be metafunctions themselves (that is, they only take type parameters.) _c_q would meet the first goal but not the second. This by itself does not preclude its inclusion, but, while the ability to omit ::value is convenient, it's not indispensable.
- It is not "template class" but "class template".
Yes, it's actually "template class", meaning a class template instantiation. A template class is a class; a class template is a template. Too subtle, perhaps, but this is correct terminology.
3.2.1 A "Requires" clause should be added to many entries.
That's correct. I'll be nailing the requirements down one by one. The choice in each case is between a hard error and a substitution failure, and it is not a trivial choice. (Although Bruno would disagree. :-) ) Thank you for the review!