Boost logo

Boost :

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at