Unlike boost::mpl::and_ etc., these functions takes other
type traits and apply them:

  composed<remove_cv_t, remove_reference_t>::call<T> -> T w/o ref, cv
  composed<is_array, remove_reference_t>::call<T>::value -> is ref to array?

  either<is_array, is_integral>::call<T>::value -> array or integer?
  both<is_integral, is_signed>::call<T>::value -> signed integer?
  neither<is_pointer, is_member_pointer>::call<T>::value

  negated<is_integral>::call<T>::value -> not an integer?

Some initial implementation can be found here:

  https://gist.github.com/lichray/6034753

Comments?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2013/10/8 Zhihao Yuan <zy@miator.net>:
> Unlike boost::mpl::and_ etc., these functions takes other
> type traits and apply them:
>
>   composed<remove_cv_t, remove_reference_t>::call<T> -> T w/o ref, cv

I find it very unfortunate that the arguments are eagerly evaluated. I
also find the name "call" quite unnatural. As written I have a hard
time to assume what the order of application is, but I guess this is
just a convention one has to get used to over time.

>   composed<is_array, remove_reference_t>::call<T>::value -> is ref to array?
>
>   either<is_array, is_integral>::call<T>::value -> array or integer?
>   both<is_integral, is_signed>::call<T>::value -> signed integer?
>   neither<is_pointer, is_member_pointer>::call<T>::value
>
>   negated<is_integral>::call<T>::value -> not an integer?

I would find the logical combinators and_, or_, and not_ much more
natural and it corresponds to existing practice by boost.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tue, Oct 8, 2013 at 2:56 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
>>   composed<remove_cv_t, remove_reference_t>::call<T> -> T w/o ref, cv
>
> I find it very unfortunate that the arguments are eagerly evaluated.

I think Boost.MPL's are the ones which do eager evaluation.  For
example, you have `or_<is_array<T>, is_integral<T>>`, Ts
are already presented.  But you can pass
`either<is_array, is_integral>::call` without passing T.

> also find the name "call" quite unnatural. As written I have a hard
> time to assume what the order of application is, but I guess this is
> just a convention one has to get used to over time.

At the beginning of using ::apply() to work around function template
specialization is also awkward :(

>>   neither<is_pointer, is_member_pointer>::call<T>::value
>>
>>   negated<is_integral>::call<T>::value -> not an integer?
>
> I would find the logical combinators and_, or_, and not_ much more
> natural and it corresponds to existing practice by boost.

They different, see above.  I usually like to work with
function of functions...

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 08/10/2013 21:11, Zhihao Yuan wrote:
> On Tue, Oct 8, 2013 at 2:56 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>>>    composed<remove_cv_t, remove_reference_t>::call<T> -> T w/o ref, cv
>> I find it very unfortunate that the arguments are eagerly evaluated.
> I think Boost.MPL's are the ones which do eager evaluation.  For
> example, you have `or_<is_array<T>, is_integral<T>>`, Ts
> are already presented.  But you can pass
> `either<is_array, is_integral>::call` without passing T.
>
The correct MPL idiom is to build a Meta-Lambda function usignmeta=20
palceholders

or_<is_array<_>, is_integral<_> >

then use apply

typedef apply< or_<is_array<_>, is_integral<_> >, T >::type r;


A old discussion on MPL was to use said "round lambda" :

typedef apply< or_( is_integral(_), is_array(_) >::type r;

to play on the function/metafunction similarity


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Tue, Oct 8, 2013 at 3:16 PM, Joel Falcou <joel.falcou@gmail.com> wrote:
> On 08/10/2013 21:11, Zhihao Yuan wrote:
> The correct MPL idiom is to build a Meta-Lambda function usignmeta
> palceholders
>
> or_<is_array<_>, is_integral<_> >
>
> then use apply
>
> typedef apply< or_<is_array<_>, is_integral<_> >, T >::type r;

But that complicates the traits implementation, right?
I think traits should be trivially implementable by users;
attempt to extend them intrusively does not look good
to me.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tue, Oct 8, 2013 at 2:56 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
>>   composed<remove_cv_t, remove_reference_t>::call<T> -> T w/o ref, cv
>
> I find it very unfortunate that the arguments are eagerly evaluated. I
> also find the name "call" quite unnatural. As written I have a hard
> time to assume what the order of application is, but I guess this is
> just a convention one has to get used to over time.

Oh, I see.  You mean call<T> gives you the type
but not a holder of ::type.  Maybe we can fix it
by having both composed and composed_t.

However, the main purpose is to adapt
integral_constant (my first implementation of
`compose` don't even work with things other
than integral_constant, maybe I should get
back to that).

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Tue, Oct 8, 2013 at 5:09 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Tue, Oct 8, 2013 at 2:56 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
>>>   composed<remove_cv_t, remove_reference_t>::call<T> -> T w/o ref, cv
>>
>> I find it very unfortunate that the arguments are eagerly evaluated. I
>> also find the name "call" quite unnatural. As written I have a hard
>> time to assume what the order of application is, but I guess this is
>> just a convention one has to get used to over time.
>
> Oh, I see.  You mean call<T> gives you the type
> but not a holder of ::type.  Maybe we can fix it
> by having both composed and composed_t.

Now it works with (only) the ::type protocol.

User side change:

from

  composed<remove_cv_t, remove_reference_t>::call<T>

to

  composed<remove_cv, remove_reference>::call<T> (::type)

composed_t does not look helpful to me, because
the use cases I care is to pass composed<...>::call
around and finally get an integral_constant, in that case
the ::type is always integral_constant...

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 10/9/13 2:38 AM, Zhihao Yuan wrote:
> Unlike boost::mpl::and_ etc., these functions takes other
> type traits and apply them:
>
>    composed<remove_cv_t, remove_reference_t>::call<T> -> T w/o ref, cv
>    composed<is_array, remove_reference_t>::call<T>::value -> is ref to array?

Another implementation with less argument lists would be composed< T,
is_array, remove_reference >. Not as intuitive on the first read, but
probably easier in the long run.

Side note: some metafunctions in the "unary type traits" section are not
unary, such as is_constructible and is_assignable.

>    either<is_array, is_integral>::call<T>::value -> array or integer?
>    both<is_integral, is_signed>::call<T>::value -> signed integer?
>    neither<is_pointer, is_member_pointer>::call<T>::value

These should be covered by constexpr initializer_list specializations of
standard algorithms. "Neither" should be "none_of," "both" should be
"all_of," and "either" should be "any_of."

>    negated<is_integral>::call<T>::value -> not an integer?

That's just perverse. The ! operator works fine.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tue, Oct 8, 2013 at 8:48 PM, David Krauss <potswa@gmail.com> wrote:
> Another implementation with less argument lists would be composed< T,
> is_array, remove_reference >. Not as intuitive on the first read, but
> probably easier in the long run.

Higher-order means, I need to pass the unevaluated
functions around.

> Side note: some metafunctions in the "unary type traits" section are not
> unary, such as is_constructible and is_assignable.

This is something I need to think of; hope I don't reach
MPL in the end ;)

New address of impl:

  https://github.com/lichray/traits_adaptors

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.