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-17 10:20:39

Joaquin M López Muñoz wrote:
> El 17/07/2017 a las 1:06, Peter Dimov via Boost escribió:
> > > 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. :-)
>
> We already have subnamespaces in std (e.g. std::chrono), so your 
> standardization plan could be realized as s/boost/std.

It could if I wanted to propose std::mp::if_, but I don't. I want to propose 
std::mp_if.

I know that this makes the library more difficult to use in other Boost 
libraries where there's no convenient place to put the using directive. :-/

> > Set operations are only provided for the cases where the generic 
> > list-based algorithm would be unsuitable or less efficient.
>
> I'm not sure this observation entirely addresses my question.
>
> * mp_set_find is not provided because mp_find does the job --OK, but 
> consider my point 1.5.1 then.
> * If mp_set_push_(back|front) is provided (no suitable list-based 
> algorithm), why not mp_map_push_back|front)?

Our disagreement here rests on whether set should be the same as map. I do 
not view them the same at all. Set is a list with an added constraint, but 
it's still a list, and list-like things can be done to it. It's lower level, 
so order matters. Map is a higher-level key-based structure, where order 
doesn't matter (logically.)

> Something more generic can be provided
>
>    struct mp_mpl_sequence_folder

It can, but it ties me to MPL, so I've chosen not to provide it.

> Additionally:
>
> *  "A metafunction is a class template or a template alias [...]": 
> s/"template alias"/"alias template"?
> * "mp_unique<L> returns a list of the same type as L [...]": being "the 
> same type" needs definition. This is found in other places throughout the 
> documentation.

You're right, the documentation is not particularly rigorous. I use C++ 
terms here and the colloquial meaning of "type" there.

I tend to think that the meaning is more or less clear, but things could be 
tightened up at the expense of terseness.