On Jul 9, 2011, at 11:39 AM, Vicente Botet wrote:
You are right and the same applies to any type-to-type conversion. And maybe this is the MAJOR flaw of Boost.Conversion: to think that we can define extrinsically THE conversion between two types. Every body admit that if a class T defines a constructor from a std::string THE conversion from std::string to T is the one defined by this constructor.
Yes, this is a problem with all global customization points. I would expect than any one developer would want to use either lexical_cast or coerce. However, does the ODR mean that the exact same conversions would have to be defined in a library and in any code that uses the library? That sounds tricky! Just document it as a known limitation and reviewers can decide
Note that this issue is not only limited to Boost.Conversion but to any function that could be overloaded by the user or any template class that can be specialized by the user. Two different parts of a program could make the same overloading or the same specialization. This doesn't implies that we should avoid overloading or specializations.
Right.
It seems clear to me that if we don't have a consensus on the default type-to-type conversion extrinsically Boost.Conversion mustn't not provide it,
IIUC it's providing the conversions and the user chooses them by #including the headers of interest.
neither the user.
? Really?
Does it means that Boost.Conversion has no sens? I don't know.
Coming back to the string to int conversion, if we can not have a default string-to-type or type-to-string, Boost.Conversion must remove these specializations.
Seems to me there are still defaults: decimal provided by either lexical_cast or coerce depending on user preferences. And the user has to be careful. Or are you saying that since all libraries linked into a program must agree on which conversions to use, Conversion should only define ones that everyone agrees on? That sounds rather extreme. Why not just stipulate that the set must be the same throughout the program? Libraries would document or allow customization of which converters they use.