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 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. :-/
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 higher-level key-based structure, where order doesn't matter (logically.)
Totally valid point of view. My intuition about mp11::map comes from the definition ("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 semantically 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 to potential users willing to migrate from Boost.MPL but wanting to do so in a progressive manner. Joaquín M López Muñoz