On 4/3/2017 2:45 AM, Louis Dionne via Boost wrote:
Dear Boost community,
The formal review of Barrett Adair's CallableTraits library begins today, April 3rd, and ends on April 12th.
CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures.
You can find the documentation of the library here:
http://badair.github.io/callable_traits/doc/html/index.html
and the GitHub repository here:
https://github.com/badair/callable_traits
We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost, and conditions for acceptance if any - Your name - Your knowledge of the problem domain
You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review?
We await your feedback!
The documentation is confusing regarding the level of C++ conformance needed to use the library. At the beginning it says that the library is a C++11/C++14/C++17 library, whatever this means. Later information explains that it is only dependent on a C++11 standard library. There is mention of compatibility claims, which further confuses the issue. Finally there is mention of static asserts or substitution failures for some functionality. Frankly with all this confusion I would be very loath to use the library as the doc explains the issue(s). It would be much clearer if the library expressed the minimum level of C++ compliance needed for the majority of the functionality and then documented any greater level of C++ conformance needed for specific functionality. Also the library should document a standard behavior when the level of conformance is not met, either internal adjustment to a lower level of conformance, compiler errors, static asserts, or run-time exceptions, depending on how the library is designed, and these need to be carefully explained if they differed for different functionality. The number 3) item in comparing callable traits to the current Boost function types needs more explanation. Having used Boost function types in code ( Boost tti uses it, and I have used it in other programming endeavors ) I do not see how the callable traits library author could think that Boost function types encourages template specializations, so maybe an example showing what is meant by item 3) would be needed to back up this claim. Please note: I am certainly not against modernizing the function type interface; I just think that claims vis a vis Boost function types need to be backed up with actual proof by example.