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
In my tiny toy library, any function can be assigned to a named parameters functor with a simple declration. http://tinytl.sourceforge.net/#func_named_params_function However the syntax for invoking it is not very pretty. cw( cw.arg<style>(3) ); cw( cw.arg<title>("hi") ); instead of cw( title = "hi" ); I was going to combine boost::named_params with my named functors (in some way at least) but never got around it... it is still on my list. I agree that the all these steps from #2 just to make a named wrapper is a bit excessive and probably unnecessary.
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.
If you have named parameters with default values, why not... Eugene