[boost] [Review] TTI

Subject: [boost] [Review] TTI
From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2011-07-26 16:19:36

What is your evaluation of the design?

Except for the namespace issue, which seems resolved, it seems to be 
what it needs to be.  I don't know that there are a lot of design 
options here.  It seems to offer a complete set of needs, from 
metafunction or trait to metafunction class.  This is good.

What is your evaluation of the implementation?

Again, I don't see a lot of room to be innovative here.  It's as clean 
as it can be I think.

One thing that I think is missing is the option to check for a named 
callable within a type.  For example, one might want to use enable_if 
style concept checking.  So long as a type has function 'xxx' that takes 
arguments of type x,y,and z, and returns something convertible to type 
A, the concept is obeyed.  I don't believe this can be done with C++03, 
but with C++1X I was able to do something using decltype.

What is your evaluation of the documentation?

Could probably use some more tutorials.

What is your evaluation of the potential usefulness of the library?

VERY.  Having to write all these things by hand is a PITA.  Most people 
who would have use for this library have probably already devised 
similar sets of macros.  It would be nice to have something somewhat 
standardized.

Did you try to use the library?

No.

How much effort did you put into your evaluation?

Quick reading.

Are you knowledgeable about the problem domain?

I think I can say yes.  I've had to write my own such SFINAE and 
overload metafunction objects numerous times.

Do you think the library should be accepted as a Boost library?

Yes, so long as the namespace issue is indeed fixed.

For thoroughness, the namespace issue is that the current implementation 
places traits and metafunction objects within the boost namespace.  The 
library would be more useful if the macro declared objects within the 
scope the macro is used.  It's an important feature that I often declare 
such objects within class scope.  Since they aren't providing 
specializations, it shouldn't be necessary to place them in the boost 
namespace and the author has agreed to discontinue this policy.