=============================================================================== Copyright (C) 2001-2007 Joel de Guzman, Dan Marsden, Tobias Schwinger Use, modification and distribution is subject to the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) =============================================================================== * Document extension::struct_size, extension::struct_member and extension::struct_assoc_member in extension section. * Document rationale behind at and value_at and how to choose which to use. * Reinstate the function object algorithms * Break all dependency cycles if there are some more * Break the view<-->algorithm dependency cycle * Improve extension docs * Document sequence/convert * Consider object equivalent of functions and algorithms (so you can do transform(iterators, deref()) with needing to put together a wrapper for deref). * Make algorithms work with mutable data * Consider segmented sequence / algorithm support * Consider utility element_ref::type thats consts and refs as appropriate * Improved motivation section * Expand details of view concept * Examples, examples, examples * look at lambda stuff * Complete the fusion/include/ directory containing a flat list of include files for all the modules and components. * The error messages when e.g. the function is not set as const are difficult to decipher. e.g. transform(s, f) <<- where f has a non-const operator() * mpl, fusion, container type preserving operations incompatible -- shall we consider container-type preserving variations of the functions/algorithms? How about making joint_view Concept preserving? This way push/pop/front/back will return a view of the same Concept. - tosh * map_tie is implemented. It seems not yet documented? - Dan: done now! * multi_set, multi_map? * why is insert_range not spelled insert_sequence ? * Document the new fusion extension mechanisms ->iterator_facade ->sequence_facade * David A: Wouldn't extension be a lot easier if iterator_base and sequence_base took (optional) 2nd arguments that specify the tag? Then you wouldn't need that whole dance that enables tag dispatching (right?) * David A: is_iterator isn't documented? JDG: There is no is_iterator ;) There is is_fusion_iterator, but it should probably be placed in detail. * for_each takes the function object by reference to const, so you have to const qualify operator() and make the data members mutable so you can change them anyway. Eric N: IMO, this is a bug in Fusion. There should be an overload of for_each that takes a function object by non-const reference. Stateful predicates should be supported, and Fusion should be explicit about where and when predicates are copied, so that the state doesn't get messed up. * Make Boost.parameters library's ArgumentPacks a conforming fusion sequence * Optimize container performance with typeof / compiler defect typeof. In particular improve the performance of the prototype deque implementation. * Deque docs if we decide we like it * Rewrite the whole extension docs section. More formal docs of extension point, example to use the various facade types, rather than hand coding everything. * zip optimization - Zip is rather compiler heavy, try and reduce the likelihood of compilers like msvc7 hitting internal compiler limits * Document the unused support added to zip for Hartmut. * Rationalize support/unused.hpp and the ignore stuff needed for tie etc. * Why do we need to set FUSION_MAX_VECTOR_SIZE when we set FUSION_MAX_MAP_SIZE? Setting FUSION_MAX_MAP_SIZE should be enough. tosh: * Document Incrementable / Single Pass Concepts * Provide infinity-aware default implementation for Incrementable Sequences Thoughts: It would probably be cleaner to have infinity conceptually orthogonal so there can be infinite Bidi/RA/Assoc Sequences. OTOH it complicates things in way that might not be worth it... * Implement always_view/always with repetitive_view > semantics - using repetitive_view will for this purpose will be way too much overhead. ? Functional wrappers for intrinsics/algorithms. * Rewrite functional benchmark ========================================================== From the fusion review (please mark all done items): 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. Dan - I like the name Fusion, and there is precendent for less direct library names like Spirit and Xpressive in Boost. (And Boost is not exactly an explicit name either). * 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. Dan - Joel added iterator and container adapters, still to be documented as part of the improved extension docs to be done by me. * 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.