Re: [boost] [conversion] ADL and templates

Subject: Re: [boost] [conversion] ADL and templates
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-06-01 07:34:54

Vicente Botet wrote:
[with minor editing by me]
>
> 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::type_tag<Target> const&);
>
> 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.

That is quite complex because of the two levels involved.

> When I introduced this complex mechanism I was expecting that
> the user could call the convert_to function without using the
> boost::conversion namespace, but this is only true if it uses
> explicitly the dummy parameter, which doesn't seems natural to
> me.

Agreed.

> 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).

Agreed.

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

Having just one CP is better.  Sure, PTS is less obvious than overloading a function template, but having to know about both mechanisms and which is necessary in various circumstances, makes the whole mechanism more complicated than it should be.

> I suspect that after refactoring, I will rename the namespace
> overload_workaround by something more positive. Any
> suggestions?

namespace boost
{
namespace conversion
{
   template <class Target, class Source, class Enable = void>
   struct converter
   {
      Target
      operator (Source const &) const;
   };
}
}

Note that I'm suggesting boost::conversion::converter<Target,Source,Enable> as the name and I'm suggesting s/apply/operator ()/ to make it a function object.  These alterations mean that there is now a function object interface for effecting conversions from Source to Target which is the sole point of customization for all such conversions in the library.

BTW, it might be wise to make the primary specialization fail, perhaps through the use of BCCL in the convert_to function template.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.