Re: [boost] [GSoC][MPL11] Post C++Now update

Subject: Re: [boost] [GSoC][MPL11] Post C++Now update
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-05-20 14:06:56

Eric Niebler <eniebler <at> boost.org> writes:

>
> On 05/19/2014 10:28 AM, Louis Dionne wrote:
> > Type-only predicate
> > -------------------
> >     struct odd {
> >         template <typename T>
> >         constexpr auto operator()(T t) const { return t % int_<2>; }
> >     };
> >
> >     static_assert(std::is_same<
> >         decltype(any(odd{}, list(int_<1>, int_<2>))),
> >         Bool<true>
> >     >::value, "");
> >
>
> What does it look like to have a compile-time list containing void? Or
> an array type? Or a function type (i.e., not a pointer to function)? Or
> an abstract type?

    static_assert(
        fmap(trait::add_pointer, list_t<void, int(), char[10]>)
        ==
        list_t<void*, int(*)(), char(*)[10]>
    , "");

    static_assert(
        head(fmap(trait::add_pointer, list_t<void, int, char>))
        ==
        type<void*>
    , "");

    static_assert(std::is_same<
        decltype(
            head(fmap(trait::add_pointer, list_t<void, int, char>))
        )::type,
        void*
    >::value, "");

Here's how it works. We provide the following helper for convenience:

    template <typename ...Xs>
    constexpr auto list_t = list(type<Xs>...);

where type<T> is a constexpr variable template of type Type<T>. Type<T>
provides a nested ::type alias to T and also provides adapted versions of
the type_traits as constexpr functions. For example, it is possible to write

    static_assert(trait::add_pointer(type<T>) == type<T*>, "");
    static_assert(std::is_same<decltype(type<T*>)::type, T*>::value, "");

Note that type<T> == type<U> is (roughly) equivalent to std::is_same<T, U>.

The way I see it is that we're trying to represent types as constexpr objects.
When trying to do that, a natural question is: what are the "methods" of these
objects? What are the operations that we can do on those objects? The answer
to that is "whatever operation we can do on a type", which correspond exactly
to the type_traits. So type_traits end up being the API of objects of type
Type<...>, which are nothing but a special case of compile-time-manipulable
objects. When we see things this way, it seems natural to think of the MPL as
a special case of heterogeneous constexpr computation.

There is still one problem that has to do with ADL (it is not limited
to type<>):

    template <bool b = false>
    struct invalid { static_assert(b, "can't instantiate invalid<>"); };

    static_assert(type<invalid<>> != type<void>, "");

This is going to assert in invalid<> because the ADL required by != will
trigger the instantiation of invalid<> . One obvious workaround is to
provide named operators like not_equal, but real operators provide a
large plus for legibility. If someone has an idea, please let me know.

Regards,
Louis Dionne