This is not a review. I may write a review later, but don't wait for it. I do however, have serious concerns about some aspects of the convert library which I would like to raise. On the subject of the "multi-purpose" function: Personally, I feel (as some others have suggested) that returning an object convertible to the "real" result type is dangerous. I am a heavy user of "auto" these days, and I would like to be able to write auto i = convert<long_type_name>::from(s); or similar things without worrying about the "surprising" result type. However, it would be easy to write a wrapper function to facilitate this use case if necessary, so I don't consider it a critical issue. I have a much bigger concern with the detailed semantics of the conversion function. One of the big issues (IMHO) with lexical_cast is the potentially surprising behaviour that can occur when the global locale is set to something other than the classic locale. It is good that convert offers the locale_ option to override the locale used for conversion, but I didn't see anywhere in the docs a clear explanation of what locale is used when none is specified. Is it the global locale or the classic locale? This needs to be mentioned clearly and conspicuously. My preference would be that the classic locale is always used unless another is specified. That allows convert to be safely used in library code that cannot know the global locale without surprises. It also allows "optimized" implementations such as that you are suggesting for string-to-bool to be inserted without changing the existing interface. The suggestion in another post that the optimized string-to-bool implementation should try "true", etc. and then fall back on a localized conversion (or, worse, that it should not support the localized conversion at all) concerns me greatly. This optimization is then changing the behaviour in non-English locales, since they will now accept "true" where before they did not. If you intend to perform this kind of breaking change in the development of Boost.Convert, then that fact also needs to be made clear and conspicuous in the documentation. Finally, I am concerned by the prospect of ODR violations as a result of specialised conversions. Taking again the string-to-bool conversion as an example: if part of a program is compiled with this optimized implementation present, and part is compiled with it absent, then I suspect the program will be in violation of the ODR. This seems really quite dangerous. In particular, I see no safe way for me to write an optimized or otherwise customized implementation of any conversion unless either (a) it is distributed as part of Boost.Convert, and included unconditionally whenever the definition of convert is, or (b) it converts to or from a type A, and is included unconditionally whenever the definition of A is. Is the extension facility intended to be used in these limited circumstances? If so, then that fact must also be clearly and conspicuously documented. If not, then I would like to know how ODR violations are to be avoided. John Bytheway