Hi Dave & Daniel Here are some general comments on the library: - What is your evaluation of the design? --------- no comments - What is your evaluation of the implementation? --------- no comments - What is your evaluation of the documentation? --------- seems ok, though I miss what impact it would have on performance. - What is your evaluation of the potential usefulness of the library? --------- low - Did you try to use the library? With what compiler? Did you have any problems? --------- no, no. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ------ a glance As always, please remember to clearly state whether you believe the library should be accepted into Boost. -------- I think it should not be accepted. My main motivation is that I think it promotes an unsound growth in function interfaces. I also miss a comparison of other techniques (eg. bgl_named_params, named_constructor_pattern) to do the same and an good explanation why this approach is superior. Let me elaborate. 1. Clearly, this is not nice window* w = new_window("alert", true, true, false, 77, 65); However, the amount of work needed to code parameters for this is quite large. A simple, effective way is just to do it like this: window* w = new_window("alert"); w->set_resizable( true ); w->set_height( 77 ); .... and you might provide chaining to make it more concise. In addition there is no forwarding problems and you might have these functions anyway. 2. what happens, then, if I don't have an object, but a free-standing function? a) wrap the function in an object b) do as in http://www.boost.org/libs/graph/doc/bgl_named_params.html c) provide overloads of functions that pack related parameters together or simply add defaults I must admit I'm a bit sceptical about functions when they start having more than 3-4 arguments; there is almost always some abstraction lurking just waiting to be done. -Thorsten