What is your evaluation of the design? My biggest design concerns at the moment: 1. The scope of the library must neccessarily be limited. It should contain the dimensional analysis framework, all predefined base and derived physical dimensions, dimensionless constants, metric prefix wrappers, possibly the SI units of measurement, and that's about it. All other dimensions, units, and systems of measurement should be treated as "localized" extensions that are built on top of this library. 2. Exponents should be tightly coupled to their respective dimension or unit. Specifying them implicitly in a list as a pair is not tightly coupled. unit< meter, 1, gram, 2, second, -1 > Make the exponent a template parameter of the dimension or unit. This syntax is more natural and more intuitive. unit< meter<1>, gram<2>, second<-1> > 3. Generally speaking, the vast majority of units are converted to one another by simply multiplying the quanity by a factor. The current proposal potentially requires a separate template specicialization for each of these conversions. This type of conversion should be generalized, if at all possible, into a single generic operation. What is your evaluation of the implementation? My biggest concerns about the implementation: 4. Many Boost libraries follow the "fine-grained" header policy (e.g. MPL) while also providing convenience headers that include entire components or the entire library with a single include directive. Looking at the proposed library, I would like to see at least one convenience header file that includes the "core" library. Also a few of the headers are rather large and should be broken into smaller headers. 5. Don't see the need for ordinal class template. How is it different from the MPL integer constant wrappers? There are also other such questionable symbols (e.g. the whole operators.hpp header, make_dimension_list). 6. Code that should ideally be included as part of other Boost libraries (e.g. static_rational as part of Boost Math) should be defined within the ideal namespace to indicate the intended namespace partitioning even if the header currently resides in the proposed library. 7. The code sometimes confuses dimensions and units. Example: boost/units/systems/si/length.hpp:22:typedef unit<length_type,SI::system> length; Length is a dimension, not a unit. The type name 'length_type' however does have a sensible definition: ./boost/units/systems/physical_units.hpp:typedef fundamental_dimension<length_tag>::type length_type; Meter however is a unit and its dimension is length but to define 'meter' as a constant, even a constant whose type is 'length', looks really suspect of a design tradeoff: ./boost/units/systems/si/length.hpp:BOOST_UNITS_STATIC_CONSTANT(meter,le ngth); Not sure about the benifits and drawbacks of such a design. What is your evaluation of the documentation? Adequate for purposes of the proposal. It would need quite a bit more work to bring it up to the level of other Boost libraries. Compared to design and implementation of such a library, this is a relatively small issue. What is your evaluation of the potential usefulness of the library? Apart from some usage issues and prototypical implementation, it's headed in the right direction. Some scientists and engineers will certainly find it useful as is but many programmers will have issues with its current form I believe. Did you try to use the library? With what compiler? Did you have any problems? I tried to build the examples on MSVC 8.0 and Mac OS X but couldn't because there is only a BoostBuild v2 Jamfile and v2 is troublesome to say the least. A v1 Jamfile would have been extremely helpful. How much effort did you put into your evaluation? Few days of code and documentation review with light experimentation and testing of the examples. Are you knowledgeable about the problem domain? Enough to design and write a similar library and thus be aware of all the issues involved with such development. Do you think the library should be accepted as a Boost library? Not in its current form. While it does demonstrate the potential for becoming a Boost library, it needs more work. Symptomatically, the authors have stated that the library is still in development and I am hesitant to formally accept any library that is still in development. I would politely recommend that the authors gather, analyze, and integrate all review commments so far. I would also encourage rigorous testing by a larger, more objective audience. Eric.