Re: [boost] [review][mp11] Formal review of Mp11

Subject: Re: [boost] [review][mp11] Formal review of Mp11
From: Peter Dimov (lists_at_[hidden])
Date: 2017-07-16 23:06:22

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<L<T1, T2, T...>> -> T2), or requires a more 
elaborate implementation (as all primitives taking an arbitrary index 
require.)

>    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!