Subject: Re: [boost] [review][mp11] Formal review of Mp11
From: Joaquin M LÃ³pez MuÃ±oz (joaquinlopezmunoz_at_[hidden])
Date: 2017-07-17 11:06:44
El 17/07/2017 a las 12:20, Peter Dimov via Boost escribiÃ³:
> 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. [...]
>> > 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
>> 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. :-/
As I see it, users of your library can be divided into three targets:
1. Regular users of Boost.
2. Boost authors (like myself).
3. Users of the std library, once this is proposed to the committee,
accepted and implemented.
My personal opinion is that 1 should be given priority, followed by 2
and, at a distance, 3.
It is a submission for Boost we're dealing here with. In that light, mp_
sounds like noise
to me (also for 3, but this is not a subject for this review).
> 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
> key-based structure, where order doesn't matter (logically.)
Totally valid point of view. My intuition about mp11::map comes from the
("a list of lists [...]") and the std::set/std::map analogy. If you want
to pull readers away
from that mindset you might want to be a little more descriptive about
what a map is
meant to be / be used for, and/or change the name to something not
overloaded like, say, "dictionary".
>> 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.
This can be confined to a dedicated header, so that the rest of Mp11 is
MPL-free and your
planned std proposal won't be polluted, and you'd be providing a service
users willing to migrate from Boost.MPL but wanting to do so in a
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk