From: "Stewart, Robert" <Robert.Stewart@sig.com> ...
int i = boost::convert::to<int>(str);
That's good.
How about we simplify the API down to just: T convert::to<T>(S, boost::parameter-list); Then we specialize it for convert::result type so that convert::result<T> convert::to<result<T>>(S, boost::parameter-list); In fact, if there is a lot of resistance to incorporate that into the lib., I can simply implement that locally. The "bool convert::try_to<>(S, T&)" API is for those who prefer that style. Then, a most-functionality-covering example might look like // The predictable. Throws on failure int i = convert::to<int>("FF", (format_ = std::hex)) // The predictable. Returns fallback on failure int i = convert::to<int>("FF", (fallback_ = 255, locale_= ..., format_ = std::hex, throw_ = true)) // The predictable. Has fallback but is forced to throw on failure int i = convert::to<int>("FF", (fallback_ = 255, locale_= ..., format_ = std::hex, throw_ = true)) // The 'try' version int v = 255; bool success = convert::try_to<int>("FF", v, (locale_= ..., format_ = std::hex)) // My personal favorite (locally implemented or incorporated into the lib.) convert::result<int> res = convert::to<result<int>>("FF", (fallback_ = 255, locale_= ..., format_ = std::hex)); There is no converter exposure. The expected Target type is returned. No implicit conversions whatsoever. When I need convert::result, I'll ask for it explicitly. Seems like that might turn nay-sayers (or no-voters) to happy customers. 'convert' would be fairly easy to re-shape like that. Or Vicente might beef-up his library and get all the fame (oooh, jealous). V.