Stewart, Robert wrote:
Vicente Botet wrote:
There is something that is troubling me on the fact that the developer will customize the conversion function using overload and ADL, but that the user could not take advantage in a simple way of this overloading. Taking in account that Boost.Conversion needs already a customization point to take care of conversion of types in the standard library (using partial specialization) the addition of the customization point using overload doesn't make simpler the user code, neither the developers customizing the class, as it would need to choose between two customization points that doesn't make any difference.
If no one find that the additional customization (via overloading) point add some benefit to the library, I will prefer to remove it. This will have the advantage of making the library quite more simple without limiting his expression power.
I have no idea to what you're referring. I've long since lost any notion of what overloads, customization points, etc. you're discussing. Can you show, with code, what the choices are and what problems you're addressing?
Hi, sorry I didn't give enough information. Currently Boost.Conversion has two customization points: A- overloading of conversion::convert_to function template (*typename Target, typename Source*) Target convert_to( Source const& from, dummy::base_tag<Target> const& p=dummy::base_tag(*Target*)()); The dummy parameter is there to allows overloading on the return type. B- partial specialization of conversion::overload_workaround::convert_to struct. namespace overload_workaround { template (* typename To, typename From, class Enable = void *) struct convert_to { static To apply(const From& val); }; The default implementation of conversion::convert_to calls to an internal function that calls to convert_to (ADL) after introducing a default implementation (via using). If the user has defined an overload that is preferred to the default one, his overload is called. If there is no better overload the default one call the conversion::overload_workaround::convert_to::apply function, which by default returns Target(from). The partial specialization part is needed as we can not add overload on the std namespace. When I introduced this complex mechanism I was expecting that the user could call the convert_to function without using the boost::conversion namesapce, but this is only true if it uses explicitly the dummy parameter, which doesn't seems natural to me. So if the user needs always to call the conversion function as follows boost::conversion::convert_to(*T*)(v) Now, I don't see any advantages to maintain the customization point (A). The customization point B alone allows to make whatever can be done with both and it simplifies quite a lot the implementation. The default conversion::convert_to function needs just to call the customization point B. I suspect that after refactoring, I will rename the namespace overload_workaround by something more positive. Any suggestions? If you need more details of the current implementation, you can take a look at the header http://svn.boost.org/svn/boost/sandbox/conversion/boost/conversion/convert_t.... Hopping this would be clear for you now. Thanks for your interest, Vicente P.S. Sorry again for the angle brackets (* *) -- View this message in context: http://boost.2283326.n4.nabble.com/conversion-ADL-and-templates-tp3561641p35... Sent from the Boost - Dev mailing list archive at Nabble.com.