Hi Vicente, I promised to react on this part:
Recently I have added some stuff to take care of ADL in the Boost.Conversion library base on the Boost.Swap library. The idea been to define a function that calls an internal function introdicing the default behavior by ADL. Thus when the user has provided some functions found by ADL they will take precedence as more specific. When not found the introduced default behavion take place.
Next follows how I have defined convert_to:
namespace boost { // trick to ensure specialization is always possible namespace dummy { template <typename T> struct base_tag {}; template <typename T> struct type_tag : public base_tag<T> {}; } // default behavior ussin gthe specialized tag type_tag namespace conversion { namespace partial_specialization_workaround { template < typename To, typename From > struct convert_to { inline static To apply(const From& val) { return To(val); } }; } template < typename To, typename From > To convert_to(const From& val, dummy::type_tag<To> const&) { return conversion::partial_specialization_workaround::convert_to<To,From>::apply(val);
} } // specialized implementation namespace conversion_impl { template <typename Target, typename Source> Target convert_to_impl(Source const& from) { using namespace boost::conversion; //use boost::conversion::convert_to if ADL fails return convert_to(from, boost::dummy::type_tag<Target>()); } } // generic function calling to the ADL introduction template <typename Target, typename Source> Target convert_to(Source const& from, boost::dummy::base_tag<Target> const& p=boost::dummy::base_tag<Target>()) { return conversion_impl::convert_to_impl<Target>(from); } }
Note that using the dummy trick we ensure that there are no infinite cycles. The default behavior could correspond to what you have already done.
If there is nothing wrong on my design, do you think that this could be also applied to the GGL library at least for the concepts?
I assume this does not have anything to do with SFINAE? I like the idea of this conversion library and I think it is also applicable to geometry. Actually we have a "convert" function which converts e.g. a box to a polygon (so from min/max go to a polygon with the points of the box). So if Boost has a generic convert_to function, we're happy to support geometries there. After reading your documentation I tried your code to my "fruit" test-classes for sfinae/tag dispatching, and was able to convert apples to pears. Tried it using two ways, one using the partial_specialization_workaround, one overloading the convert_to with the dummy-tag. Added namespace to check ADL and all is working nicely. To refer to your question. "At least for the concepts", you probably mean the geometry concepts. Adapting geometries to concepts is not done using free functions. It is implemented using traits classes they should be implemented in namespace ggl::traits. If you refer to the algorithms, like area, yes, I think it could be done like this in GGL, also combined with tag dispatching. But it is currently not done like this. Example c04_a and c04_b show how functionality can be overriden by specializing either the function or (partly) specializing the dispatch structure. This is all in namespace GGL. You're adding a possibility to be able to specialize in your own namespace, and I think it would be feasable, though I'm not sure if it is really expected. Regards, Barend