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
> 1.3 I find that these metafunctions are missing/misplaced:
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)
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
> 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
> 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!