[review][mp11] Formal review of Mp11

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
El 17/07/2017 a las 1:24, Peter Dimov via Boost escribió:
> Joaquin M López Muñoz wrote:
>
>> 1.7 mp_eval[_xx] functions should accept metafunctions in both their
>> true and
>> false branches.
>
> I can't make this work. [...]

This is most unfortunate. My original concern remains though that there's no
reason why one of the two branches of mp_eval_if should not accept a
metafunction
(and note the irony that mp_eval_if<B,...> precisely does not eval when
B holds). If
syntax can't be made to work, it could be advisable to drop mp_eval_if
altogether and provide for instance mp_apply_if:

   mp_apply_if<B,F,mp_list<T...>,G,mp_list<U...>>

Joaquín M López Muñoz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 17/07/2017 a las 3:11, Peter Dimov via Boost escribió:

> Joaquin M López Muñoz wrote:
>
>> 1.4 Tuple operations are named differently from their C++14/17
>> counterparts to "avoid ambiguities when both are visible or in
>> unqualified calls". Yet, this policy is not followed in
>> integer_sequence.hpp. I'd rather go the latter way.
>
> The primitives in integer_sequence.hpp are template aliases, so
> argument-dependent lookup does not
> apply to them. The tuple functions are, well, functions, and when
> f.ex. make_from_tuple<T>(tp) is
> called with an std::tuple, ADL finds std::make_from_tuple because std
> is an associated namespace.
> So the code suddenly becomes ambiguous in C++17.

You can replace your implementation with using std::make_from_tuple when
the latter is available.
After all, the perceived intention of these functions is precisely to
serve as a substitute in wait for
C++17 to arrive.

Same goes for integer_sequence.hpp, even if the conditions for collision
are different.

Joaquín M López Muñoz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Brook Milligan wrote:
> >> - mp_is_map: type trait to determine whether a type is a map, i.e., has
> >> a unique set of keys
> >
> > This is mp_is_set<mp_map_keys<M>>, although not quite if M has an
> > element that is not a list.
>
> Yes, that was also my implementation.  I just punted on the question of
> whether or not mp_map_keys would always work.  Given that it might not,
> this could be motivation for a more robust implementation in the library.

This also raises the question of what mp_is_set should do when passed
something that is not a list - return false or cause a substitution failure
(which in turn hints at the lack of mp_is_list as well).

Thank you for you suggestions. They make sense and I'll probably add them.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Joaquin M López Muñoz wrote:

> You can replace your implementation with using std::make_from_tuple when
> the latter is available.

You can still replace construct_from_tuple, you're just not forced to
because the code doesn't break.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Joaquin M López Muñoz wrote:

> If syntax can't be made to work, it could be advisable to drop mp_eval_if
> altogether and provide for instance mp_apply_if:
>
>    mp_apply_if<B,F,mp_list<T...>,G,mp_list<U...>>

Given that the one function formulation covers a significant majority of the
practical use cases, dropping it in favor of mp_apply_if would be a
significant regression in usability.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
> > 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.
> :-/

To expand on this a bit:

There are, in general, two main modes of use of Mp11, serving two audiences.
One is the "easy mode", where one includes <boost/mp11.hpp>, combines that
with `using namespace boost::mp11;`, then goes ahead using mp_this and
mp_that without qualification. This serves (a) people who play with
metaprogramming in short test cases, (b) people who have a need for a
metaprogram in a .cpp file (or an internal header file not meant for public
consumption), whether library or application one.

Mode two is in use in header-only libraries. There the library author is
generally reluctant to employ the using directive, which forces the
comparatively awkward mp11::mp_this style.

I realize that my choice gives preference to case one at the expense of case
two.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 17/07/2017 a las 11:54, Peter Dimov via Boost escribió:
> Joaquin M López Muñoz wrote:
>
>> You can replace your implementation with using std::make_from_tuple
>> when the latter is available.
>
> You can still replace construct_from_tuple, you're just not forced to
> because the code doesn't break.

Not totally sure I got my point across: I mean, if you decided to rename
construct_from_tuple as
make_from_tuple, your internal lib code can detect whether
std::make_from_tuple exists and,
in this case, replace boost:mp11::make_from_tuple definition with a
using std::make_from_tuple
declaration:

namespace boost{ namespace mp11{

#ifndef __cpp_lib_make_from_tuple
template<class T, class Tp> T make_from_tuple(Tp&& tp){...}
#else
using std::make_from_tuple;
#endif

}}

No ambiguities would then arise.

Joaquín M López Muñoz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 17/07/2017 a las 13:05, Peter Dimov via Boost escribió:

>
> To expand on this a bit:
>
> There are, in general, two main modes of use of Mp11, serving two
> audiences.
> One is the "easy mode", where one includes <boost/mp11.hpp>, combines that
> with `using namespace boost::mp11;`, then goes ahead using mp_this and
> mp_that
> without qualification. This serves (a) people who play with
> metaprogramming
> in short test cases, (b) people who have a need for a metaprogram in a
> .cpp file
> (or an internal header file not meant for public consumption), whether
> library or
> application one.

These people would be equally served by instructing them to

   namespace mp=boost::mp11;

and then go ahead with mp::this and mp::that.

Joaquín M López Muñoz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Jul 17, 2017 at 1:06 AM, Peter Dimov via Boost <
[hidden email]> wrote:

> Joaquin M López Muñoz wrote:
>
>> Porting from / coexisting with Boost.MPL would be greatly aided by some
>> utility function to convert Boost.MPL sequences to Mp11 lists:
>>
>
> ...
>
> This unfortunately doesn't work in general - as Bruno Dutra explained to
> me - because MPL operations on, f.ex. mpl::vector, do not necessarily
> return an mpl::vector.


This reads backwards to me.

It's true that the signature (i.e. types) of Boost.MPL containers are left
unspecified and, indeed, on some platforms mpl::vector is implemented via
inheritance through opaque proxy types, but that only means one can't
simply rely on the property that any instance of a variadic template class
is a List to advertise seamless interoperation with Boost.MPL, which is
also aggravated by the fact it emulates variadic parameters packs via
default template arguments.

The alternative, which seems to be what Joaquin proposes here, is to
provide a utility metafunction that explicitly converts from Boost.MPL
containers into variadic Lists and one simple way of doing it is to use
mpl::fold to push the elements of Boost.MPL containers one by one into a
variadic List by means of a custom Metafunction Class in the Boost.MPL
sense.

Bruno

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
I am interested in MP11 and will submit a review before the end of the review period.

I want to make some comments in advance of this on some topics which I have not seen discussed already.  These particularly relate to mp_quote_trait which I am finding very useful to adapt old C++03 code.

In my initial work using MP11 I found that the examples given in the documentation contained some features which are not C++11 but instead C++14 or later.  As I am wanting to adapt code from C++03 it is not helpful to have things which do not compile with C++11 only.

I am particularly interested in code which works out return types for functions where the application can be polymorphic.  The origins of much of this code are quite old now, originating with FC++ although there are more modern versions in Boost Phoenix. See for example http://www.boost.org/doc/libs/1_64_0/libs/phoenix/doc/html/phoenix/lazy_list/background.html

One item in MP11 which I have found useful is mp_quote_trait.  This seems to be a late addition to the code as it was not in the first version of the code I downloaded.  One thing which was not clear to me in the documentation was how to use the resulting object.  I looked for things with “q” in the name.  The answer to this is mp_invoke which does not have a “q”.

Example:

using mp_q_common_type_t = mp_quote_trait<std::common_type>;
template <class... T> using result_q_t = mp_invoke<mp_q_common_type_t, T...>;

This is very helpful as the resulting code works with C++11 avoiding the need to define common_type_t  which is only introduced in C++14.

I have also used the following extensions to MP11 invented to handle case where the struct to be quoted has int N at start o the list of types.

        template<template<int, class...> class F> struct mp_quote_trait_N
        {
          template<int N, class... TN> using fn = typename F<N, TN...>::type;
        };

        template<class Q, int N, class... TN> using mp_invoke_N = typename Q::template fn<N,TN...>;


One application if this is the specialization the result type from a function FF with different numbers of arguments.

        using mp_q_result_of_t = mp_quote_trait<boost::result_of>;
        template <int N, typename FF, typename... XYZ> struct RTHelper;
        template <typename FF,typename A> struct RTHelper <1,FF,A>
        {
            typedef mp_invoke<mp_q_result_of_t,F(A)> type;
        };

and for N=2, 3 etc.

I hope this is helpful

Best wishes

John Fletcher






_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
Fletcher, John P wrote:

> In my initial work using MP11 I found that the examples given in the
> documentation contained some features which are not C++11 but instead
> C++14 or later.  As I am wanting to adapt code from C++03 it is not
> helpful to have things which do not compile with C++11 only.

I went over these at one point and tried to either remove the C++14-isms, or
mention their use and provide a C++11 alternative.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list

________________________________________
From: Boost [[hidden email]] on behalf of Peter Dimov via Boost [[hidden email]]
Sent: 17 July 2017 16:20
To: [hidden email]
Cc: Peter Dimov
Subject: Re: [boost] [review][mp11] Formal review of Mp11

> Fletcher, John P wrote:

> > In my initial work using MP11 I found that the examples given in the
> > documentation contained some features which are not C++11 but instead
> > C++14 or later.  As I am wanting to adapt code from C++03 it is not
> > helpful to have things which do not compile with C++11 only.

> I went over these at one point and tried to either remove the C++14-isms, or
> mention their use and provide a C++11 alternative.

Thank you for that - it has made things clear to me now.

John

_______________________________________________
Unsubscribe & other changes: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=02%7C01%7CJ.P.Fletcher%40aston.ac.uk%7C350ec137efc54797930c08d4cd275bdd%7Ca085950c4c2544d5945ab852fa44a221%7C0%7C0%7C636359016309074831&sdata=tfC%2BwHzgIHaV%2BISUtc44s10g9KVuUdKtyXc3vq%2F7kog%3D&reserved=0

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Brook Milligan wrote:

> Nevertheless, in my code, I have found need for the following additional
> metafunctions:
>
> - mp_map_keys: creates a list of keys from a map

https://github.com/pdimov/mp11/commit/50d35a29644bfb051316ae9a21f2f7b6dbe91836

> - mp_is_map: type trait to determine whether a type is a map, i.e., has a
> unique set of keys

https://github.com/pdimov/mp11/commit/34946d2ae25a1e113c23c6ead3c55224695a7bbf

> - mp_is_set: type trait to determine whether a type is a set, i.e., has
> unique elements

https://github.com/pdimov/mp11/commit/27d0d547ee4d0cb83b678b176c8e96cb78de19b5


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Joaquin M López Muñoz wrote:

> Something more generic can be provided
>
>    struct mp_mpl_sequence_folder
>    {
>      template<typename T,typename L>
>      struct apply{using type=mp_push_front<T,L>;};
>    };
>
>    template<typename MplSequence>
>    struct mp_mpl_sequence_impl:boost::mpl::reverse_fold<
>      MplSequence,
>      mp_list<>,
>      mp_mpl_sequence_folder
>    >{};
>
>    template<typename MplSequence>
>    using mp_mpl_sequence=typename mp_mpl_sequence_impl<MplSequence>::type;

How about we provide it in MPL instead?

namespace mpl {

template<class Seq, template<class...> class L = std::tuple> using to_tuple
= /*as above*/

}

to_tuple subject to bikeshedding (to_variadic? as_variadic_sequence?).


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
El 17/07/2017 a las 23:03, Peter Dimov via Boost escribió:

> Joaquin M López Muñoz wrote:
>> Something more generic can be provided
>>
>>   [...]
>>
>>    template<typename MplSequence>
>>    using mp_mpl_sequence=typename
>> mp_mpl_sequence_impl<MplSequence>::type;
>
> How about we provide it in MPL instead?
>
> namespace mpl {
>
> template<class Seq, template<class...> class L = std::tuple> using
> to_tuple = /*as above*/
>
> }
>
> to_tuple subject to bikeshedding (to_variadic? as_variadic_sequence?).

Well, I guess users don't care where the utility belongs as long as it's
documented and available
somewhere. If you want to integrate with MPL nicely, this probably
should take the form of a
variadic sequence inserter
(http://www.boost.org/libs/mpl/doc/refmanual/inserter.html ).
Something like:

   struct variadic_inserter_op
   {
     template<template<typename...> class L,typename... Ts,typename T>
     static L<Ts...,T> helper(L<Ts...>,T);

     template<typename L,typename T>
     struct apply
     {
       using type=decltype(helper(std::declval<L>(),std::declval<T>()));
     };
   };

   template<template <typename...> class L>
   struct
variadic_inserter:boost::mpl::inserter<L<>,variadic_inserter_op>{};

   template<class Seq,template<typename...> class L=std::tuple>
   using to_variadic_sequence=boost::mpl::copy<Seq,variadic_inserter<L>>;

Note that this would be the only C++11 piece of code in Boost.MPL.

Joaquín M López Muñoz




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
On Tue, Jul 18, 2017 at 9:58 AM, Joaquin M López Muñoz via Boost <
[hidden email]> wrote:

> El 17/07/2017 a las 23:03, Peter Dimov via Boost escribió:
>
>> Joaquin M López Muñoz wrote:
>>
>>> Something more generic can be provided
>>>
>>>   [...]
>>>
>>>    template<typename MplSequence>
>>>    using mp_mpl_sequence=typename mp_mpl_sequence_impl<MplSequen
>>> ce>::type;
>>>
>>
>> How about we provide it in MPL instead?
>>
>> namespace mpl {
>>
>> template<class Seq, template<class...> class L = std::tuple> using
>> to_tuple = /*as above*/
>>
>> }
>>
>> to_tuple subject to bikeshedding (to_variadic? as_variadic_sequence?).
>
>
Personally I think this doesn't belong to MPL.

Actually I suggest providing a slightly more general utility that not
only converts MPL Sequences, but Metafunction Classes as well and also in a
recursive fashion, that is, Sequences of Sequences would be converted to
variadic Lists of variadic Lists for example.

Metal used to provide such a utility up until recently, when I decided to
remove it, but maybe it can still serve as a source of inspiration [1].
Some usage examples are available as well [2].

[1]:
https://github.com/brunocodutra/metal/blob/85d6d32f6e58e648c4573189f8bf2d7633604f27/include/metal/external/mpl.hpp
[2]:
https://github.com/brunocodutra/metal/blob/85d6d32f6e58e648c4573189f8bf2d7633604f27/example/src/mpl.cpp#L10

Bruno

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
Bruno Dutra wrote:

> >> How about we provide it in MPL instead?
> >>
> >> namespace mpl {
> >>
> >> template<class Seq, template<class...> class L = std::tuple> using
> >> to_tuple = /*as above*/
> >>
> >> }
...

> Personally I think this doesn't belong to MPL.

A cursory search seems to show that the desire to use std::tuple with MPL is
not uncommon, although getting a tuple out of an MPL sequence is of course
only half of the story, people also want to use std::tuple as if it were an
MPL sequence.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review][mp11] Formal review of Mp11

Boost - Dev mailing list
> > Personally I think this doesn't belong to MPL.
>
> A cursory search seems to show that the desire to use std::tuple with MPL
> is not uncommon, although getting a tuple out of an MPL sequence is of
> course only half of the story, people also want to use std::tuple as if it
> were an MPL sequence.

I've decided to provide the latter instead. That is, upon inclusion of
<boost/mp11/mpl.hpp>, both mp_list and std::tuple become MPL sequences and
can be manipulated with MPL algorithms. This implies the ability to convert
an arbitrary MPL sequence into an mp_list or std::tuple, via mpl::copy<Seq,
mpl::back_inserter<mp_list<>>>::type.

https://github.com/pdimov/mp11/blob/feature/mpl/include/boost/mp11/mpl.hpp
https://github.com/pdimov/mp11/blob/feature/mpl/test/mpl.cpp


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123
Loading...