[Boost-announce] [review] Fusion Library Accepted

From: Ronald Garcia (garcia_at_[hidden])
Date: 2006-06-05 11:18:27

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