diff --git a/todo.txt b/todo.txt new file mode 100644 index 00000000..2add4cc8 --- /dev/null +++ b/todo.txt @@ -0,0 +1,185 @@ +=============================================================================== +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. +