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