Correction. I meant to say the following namespace boost { template<class TypeIn, class TypeOut, class Enable =void> class convert; } // string-to-type specialization template<class StringIn, class TypeOut> class convert< StringIn, TypeOut, typename boost::enable_if_c< is_string<StringIn>::value && !is_string<TypeOut>::value, void>::type> > { convert(StringIn const&, TypeOut const& =TypeOut()); operator TypeOut const& () const {...} static TypeOut apply(StringIn const&) { ...} }; int string_to_int = convert<string, int>(str, -1); int string_to_int = convert<string, int>(str); convert<string, int> string_to_int(str, -1); convert<string, int> string_to_int = convert<string, int>(str, -1); std::transform( integers.begin(), integer.end(), std::back_inserter(strings), convert<string, int>::apply); As you can see there is *no* type-deducing. That is, with that approach we'll have to always indicate 'to' and 'from' types. That seems verbose... but might be a plus as it takes *any* ambiguity out. That gives us a lot of freedom. Like 1. using boost::convert; 2. typedef boost::convert<string, int> StringToInt; 3. optimization can be done on individual type-to-type or category-to-category basis 4. any specific exotic conversion can be added on when needed basis and locally by the user. 5. conversion-specific methods can be added to individual conversions or constructors extended (as in one of Scott's examples: struct convert< string, int, enable_if> { convert(string, int) convert(string, int, rounding) // Added special constructor } V.