Another thought that could prove interesting -- I could support a more concise syntax along the lines of the following (note the lack of "template" and any specific types being mentioned): ////////// BOOST_CONCEPT_FUNCTION ( (foo)( (forward_iterator)( it ) ) , explicit decltype( it ) ) // Or even with references BOOST_CONCEPT_FUNCTION ( (bar)( (forward_iterator&)( it ) ) , explicit decltype( it ) ) // Mix it with automatically deduced return types BOOST_CONCEPT_FUNCTION ( (bar)( (forward_iterator&)( it ) ) , ( return ++it ) ) ////////// The above macro invocations would implicitly create templates without the user having to do it manually. The idea here is that for "BOOST_CONCEPT_FUNCTION", instead of using specific types in the parameter list you'd use concepts, at least by default, and you avoid having to explicitly create template parameters. If the types are needed in the function, you can always use decltype( argument ). There are some issues here still, for instance, what if this template needs arguments for additional reasons (I.E. explicit template arguments such as with Boost.Fusion "at", though in cases like that you could always have the type instead be an MPL integral constant passed as a function argument, specified as a parameter modeling such a concept, which has the positive implications of being automatically concept checked as well as more self-documenting). Another concern is what if you need something analogous to this: ////////// template< class It > void advance( It& it, typename ::std::iterator_traits< It >::difference_type difference ); ////////// I'd have to work in syntax such as the following (which I believe may be possible to do exactly as written, with some more awful hacks): ////////// BOOST_CONCEPT_FUNCTION ( (advance)( (forward_iterator&)( it ), (concept_map_of( it )::difference_type)(difference) ) , explicit void ) ////////// The latter would be able to do everything that the former can in about the same amount of code but with concept checking on top. This is all just hypothetical but should be possible. I'm really getting too far ahead of myself now, though. -- -Matt Calabrese