Re: [boost] [conversion] ADL and templates

Subject: Re: [boost] [conversion] ADL and templates
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-05-31 16:06:46

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_to.hpp.

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-tp3561641p3564189.html
Sent from the Boost - Dev mailing list archive at Nabble.com.