Emil Dotchevski wrote:
Now, the user of uuid.hpp can also #include "boost/convert.hpp" when making calls to convert. This could provide generic overloads that support common conversion options, which would bind only if uuid.hpp doesn't provide overloads itself (which would obviously be more specialized and the overload resolution will prefer them over the convert.hpp generics.) I can't imagine how the generic convert.hpp could provide support for additional conversion options for user::uuid.
Additional conversion options that are specific to converting user::uuid to string shouldn't be a concern for the generic convert framework. The caller can pass such additional arguments if user::uuid provides overloads that take them; if not then the caller will get a compile error, which is also appropriate.
I think that'll make too many of these overloads, with an added confusion on the user's side, who has to remember the order of these options in the overloads. I certainly like named arguments more.