In the course of refactoring my multi-state mazes library to use Boost.NamedParams, I discovered that I couldn't create a default predecessor map without the proper vertex type, and I couldn't get that type without knowing the type of the input graph. So I went ahead and created a metafunction called find_named_param that helped me to accomplish this task. For example, you have the following tag types for your key words: struct input_graph_t; struct input_index_map_t; ... Then in your function, you can extract your types like so: typedef typename find_named_param< Params , input_graph_t >::type InputGraph; typedef typename find_named_param< Params , input_index_map_t , property_map< InputGraph , vertex_index_t > >::type InputIndexMap; Thus, given the following keywords: keyword<input_graph_t> input_graph; keyword<input_index_map_t> input_index_map; Assignment becomes less tedious: InputGraph& in_g = p[input_graph]; InputIndexMap index_map = p[ input_index_map | get(vertex_index_t(), in_g) ]; The third template parameter in find_named_param is the type whose member typedef ::type will be returned if the named parameter is unspecified. Of course, leaving this template parameter unspecified will result in a compile-time error if the function requires the named parameter. The corresponding argument type should be the same as (or assignment-compatible with) the type of the default value of the named parameter. The changes made to <boost/named_params.hpp>, in addition to effectively removing the dependency on BOOST_MPL_LIMIT_METAFUNCTION_ARITY, now include moving typedef H head_type; typedef T tail_type; out of the conditional macro body while remaining in detail::list, and adding the necessary functionality to make find_named_param work. I wouldn't call it sufficiently tested; however, the attached program works under MinGW (GCC 3.2) and MSVC 7.1. Happy Thanksgiving! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail