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
