boost_fusion/todo.txt

===============================================================================
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)
===============================================================================

* Provide macros for adapting classes, similar to BOOST_FUSION_ADAPT_STRUCT
  and BOOST_FUSION_ADAPT_ASSOC_STRUCT, but with with user control over
  member accessors (e.g. get and set free functions).

* 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<Seq,Member>::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<single_view<T> >
  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.