Re: [boost] [tti] review

Subject: Re: [boost] [tti] review
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2011-07-17 22:00:04

> From: jeffrey.hellrung_at_[hidden]
>
> On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge <zeratul976_at_[hidden]>wrote:
>
> >
> > > On 7/17/2011 4:10 PM, Edward Diener wrote:
> > >
> > > > I agree with Jeff's suggestion that the matching metafunction should
> > take a metafunction that defaults to is_same rather than always testing for
> > type equality (and now I see why he was also suggesting that in the Type
> > Traits Extension review :).
> > >
> > > I will look further into adding this but I strongly feel that I should
> > > not drop the simple functionality currently provided, where the end-user
> > > can just pass an actual type.
> >
> > As a casual Boost user, I would welcome this. I would find TTI very
> > useful, but I do not know MPL beyond the very basics, and I'd rather not
> > have to learn it just so that I can use TTI. I think others may be in
> > the same position.
> >
>
> My initial response is, grab a beer and go learn about Boost.MPL lambda
> expressions, you'll be happy you did (at worst, you're +1 drunk beer).
>
> Okay, my secondary response: I don't think it's really that bad to write
>
> has_type_xxx< T, boost::is_same< boost::mpl::_1, U > > // my proposed query
>
> rather than
>
> has_type_xxx< T, U > // current query
>
> (a) How often do you *really* want to check that T::xxx is precisely U? I
> think, much more frequently, you'll just want has_type_xxx<T>. And I'm
> *not* proposing to get rid of *that*.
> (b) To me, the former states more explicitly how U ties into the query.
> (c) With the current has_type_xxx semantics, it's going to get onerous one
> metaprogramming day when boost::is_same< boost::mpl::_1, U > just isn't want
> what you want. You want to check if T::xxx is an object type. Or whether
> it's const-qualified. Or any of a number of other properties in
> Boost.TypeTraits. Or :: gasp :: whether T::xxx itself has a nested type yyy
> :)

I suppose, as long as the TTI docs show some clear examples of how to use
the MPL lambdas in the most common cases, rather than just saying "any
MPL lambda can be used here" and referring you to the MPL docs, it should 
be fine. I just don't think users should have to go off and learn about
MPL lambdas by reading some separate documentation, just to be able to
make a simple use of this TTI feature.
 
Apart from that concern, I *do* see the value in being able to check for 
other things besides the types being the same, and I think it would be
a useful addition.
 
Regards,
Nate.