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.