Re: [boost] review request: addition to type_traits library of has_operator_xxx

Subject: Re: [boost] review request: addition to type_traits library of has_operator_xxx
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-11-17 15:44:50

On 11/17/2010 12:26 PM, Stewart, Robert wrote:
> Jeffrey Lee Hellrung, Jr. wrote:
>> On 11/17/2010 6:58 AM, Stewart, Robert wrote:
>>> Jeffrey Lee Hellrung, Jr. wrote:
>>>>
>>>> One thing that I've either found useful is to have an additional
>>>> template parameter in addition to the parameter types and
>>>> the return
>>>> type, which is a Boost.MPL metapredicate intended to be
>>>> applied to the actual result of the operation.  The trait then
>>>> evaluates to true only if the actual result type satisfies
>>>> the given Boost.MPL metapredicate.
>>>
>>> Perhaps checking for convertible-to-return-type could be
>>> the default predicate rather than adding another template parameter?
>>
>> How do you envision the interface then?  Are you suggesting that the
>> convertible-to-return-type type and the Boost.MPL metapredicate occupy
>> the same template parameter?
>
> Yes
>
>> To be clear, I'm suggesting something like
>>
>> template<  class T0, class T1 = T0, class Result = void,
>>     class ResultCond = boost::mpl::always<  boost::true_type>  >
>> struct is_less_than_comparable;
>
> I'm thinking something like this:
>
> template
> <
>     class T
>     , class U = T
>     , class Pred = boost::type_traits::result_converts_to<void>
>>
> struct is_less_than_comparable;
>
> boost::type_traits::result_converts_to<void>  should inherit from boost::true_type, of course.
>
>> It seems to me that, by far, the common case is checking
>> convertibility to some given type, so I think it makes sense to make
>> the common case syntactically simple.
>
> is_less_than_comparable<int, int, bool>  would become is_less_than_comparable<int, int, result_converts_to<bool>  >  which is more verbose but also more obvious and indicative of the additional power.

Okay.  I don't like the verbosity but it's a minor issue.

>> If you want to avoid the extra template parameter, maybe you can wrap
>> the predicate in something which could be detected in the Result
>> template parameter, e.g.,
>
> That would be ideal, but I'm not sure there's a satisfying means to do so without imposing too much on the acceptable predicates.

The mechanism I gave doesn't impose anything on the predicate (as far as 
I can see).  It does exclude return types that are instances of the 
wrapper, but I think that is acceptable.

- Jeff