It just occurred to me as I was writing the docs (it's amazing how writing documentation clarifies design issues!) that for the parameters library, "The Forwarding Problem" usually isn't really as bad as it might seem. In a family of overloaded forwarding functions, the only positions in which we need a T&/T const& overload pair are those in which the corresponding parameter is an out (or in/out) parameter. When passed non-positionally, the const/non-const issue is handled by the overloaded operator= on the keyword objects. So I'm thinking the macros for generating the overloads, in the next release at least, should just take care of generating the right overloads. For example, something like BOOST_NAMED_PARAMETER_FUNCTION( void, depth_first_search, (required(in))(in)(in)(out)(in) ) might work. For reference, the docs for depth_first_search are at http://www.boost.org/libs/graph/doc/depth_first_search.html Here I am assuming that the parameter order would be: graph visitor index_map color_map root_vertex [Doug, I am a little concerned about how to translatate the interface for tutorial purposes, since the documented positional interfaces don't include an overload that takes 5 parameters: index_map can only be passed as a named parameter! I don't want to confuse people. Could you take a look at libs/parameter/doc/html/index.html and give your feedback? -- Thanks] Of course, this idea doesn't work out so well for an unnamed parameter interface, which we're also going to support after 1.33. But that's a separate macro ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com