On Jul 11, 2011, at 12:59 PM, Vicente Botet wrote:
Yes, this is exactly the point. There couldn't be a conflict in the whole program. Library authors could document the conversions choices they have taken, but the use of a non-consensual conversion will make the library less usable.
I don't think that Boost.Conversion can provide a string-to-type conversion that is configurable. It could provide one if there is a consensus of a default. We should see Boost.Conversion customization as if we were adding some methods to one of the classes. For the string to float conversions, it is as if we were adding
explicit operator float() const;
to the std::string class.
Why not provide the functionality in mutually-exclusive headers, e.g. #error out in conversion/boost/coerce-strings.hpp if you see that lexical_cast-strings.hpp has already been included? This wouldn't prevent all ODR violations but it would catch any in the same compilation unit. I suppose there is a fancier metaprogramming way to detect conflicts in general (within a TU), but this is cheap. And then define none by default. That seems to be harmonious with the rest of the design, where one #includes exactly the functionality one needs. Cheers, Gordon