Dear All, I am pleased to announce that the Fusion compile-time/run-time hybrid heterogeneous container and algorithm library by Joel de Guzman and Dan Marsden has been accepted into Boost. The library received 7 YES votes and 0 NO votes, with one abstention. Detailed Review Comments ------------------------ The following comments refer to issues that the library authors should address prior to merging the library into CVS: * Documentation: Many of the reviewers stated that they would like to see more tutorial documentation that demonstrates not only what the particular constructs in Fusion do, but also how they are expected to be used. A reasonably concise motivating example has been requested. It has already been pointed out that Fusion is used for some other boost libraries. A well-developed and self-contained case study of when and how to use Fusion would be greatly appreciated. The relationship between this library and the current Boost.Tuple library, as well as Boost.Mpl, should be discussed. The reference documentation is quite thorough and detailed comments regarding them have already been addressed by the authors. However the notion of "views" requires greater documentation. The examples in the algorithm sections currently do little more than demonstrate the syntax by which they can be called. Examples that more specifically express intent would be a notable improvement. (see for example Matt Austern's "Generic Programming and the STL"). In general the documentation would benefit from copy-editing. * Several commented on the use of the name "pair" for the fusion type that has typedefs for two types but only contains the second type. Although the typedefs and member names are consistent with the std::pair object, the name "pair" is confusing. The compile-time/run-time hybrid nature of this library makes it difficult to find perfect metaphors for constructs in the library. In this case, it seems better to find a term for this template (and the concept that it models) that more directly states its purpose. The name "tag_of" would also benefit from renaming. * The behavior of Fusion functions in the face of argument-dependent lookup (ADL) is not well specified. This should be made explicit in the reference documentation. The following comments refer to issues that, while not mandatory, deserve consideration: * The library name "Fusion", though not arbitrary, says little about the library's purpose. There is precedent for this within boost, however. A name change is not mandatory for the library's acceptance, but it would be worth while for the authors to consider a more telling name. * The mechanism for extending Fusion with new containers and iterators is complex and involves implementing a number of components, especially regarding iterators. An adaptation layer that is analogous to the Boost.Iterator library would be a fine addition to Fusion. * It would be beneficial to supply Boost.Serialization support for the Fusion container types. I am sure, as mentioned, that the authors of this library would accept a volunteer to implement this functionality. I would like to thank all the people who reviewed the library, voted, and otherwise participated in the discussion. Congratulations to Joel and Dan and I look forward to seeing Fusion in the Boost CVS soon. Ron Garcia