Re: [boost] [review] Fusion review

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-05-06 09:56:50

* Documentation

1. A quick reference / one-page index is needed real badly! It takes far too many clicks to get from one component to the other.

2. Some examples are needed - illustration of common practice is a must for this library.

3. MPL (especially MPL-Lambda) interoperability must be outlined in more detail (or is the user expected to wire the result functions in terms of "typename ... >::type")? Sometimes the nested metafunction is called "apply" in the examples (an artefact?) and the function object with its "result" metafunction is said to refine an MPL metafunction class that uses "apply" instead. What?!

The structure seems a bit over-categorized to me and sometimes even misleading (e.g. when looking for fusion::pair I have to navigate to "Support" where my first guess would be "Containers", "Sequence"->"Views" is another example).

The concept of views, the impact of cv-qualification and by-reference/by-value passing should be outlined in more detail (or is it somewhere and I was unable to find it?). 

* Design

1. I'm missing an extension point in the generators to turn them into a type-preserving variadic input facility. Elaboration:

Currently e.g. "make_vector" is an inline function. My suggestion is to turn it into a global constant of the type of a class template instantiation e.g. "vector_generator<F>".

  vector_generator<identity_function> const make_vector = ...

This way it's easy to create user-defined function objects, that take a variable number of arguments, turn them into a tuple and finally use this information to create a user-defined object (that is, entirely without using Boost.PP). Of course that beast would be able to take a stateful functor in its ctor.

2. I'm also missing a fusion-equivalent to mpl::unpack_args (that would be about the inverse of 1).

The header structure seems a bit over-categorized and counter intuitive -- maybe the categorization chosen makes sense from an implementor's perspective but it might be too much for the user (maybe improved docs can sort this out).

* Implementation

Fine. Maybe could use already-preprocessed files to speed up compilation times...

* Potential usefulness

A must-have for those who reprogram their compilers and indirectly useful for those who use libraries that do so.

* Did you try to use the library? With what compiler? Did you have any problems?

Yes. 

I used it with several compilers, such as GCC and different versions of VisualC++.

Initially I had severe problems finding out which parts in the result computation require const qualification (had to read the source for reference), I still don't know the preferred way of using MPL-lambda for specifying the result (the source doesn't do it this way, I guess for compile time efficiency) and I had some problems following the "namespace result_of scheme" due to ambiguous template names (ADL, VisualC++ only).

I'm still playing with it and hope I can add some details here, soon.

* How much effort did you put into your evaluation? A glance? A quick reading? 
 In-depth study?

I'd say nearly an in-depth study, so far.

* Are you knowledgeable about the problem domain?

Yes.

* Should the library be accepted as a Boost library?

Yes, please! I hope the numbered paragraphs can be addressed beforehand, though.