Re: [boost] [conversion] Motivation for two NEW generic conver_to and assign_to functions

Subject: Re: [boost] [conversion] Motivation for two NEW generic conver_to and assign_to functions
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2009-10-26 14:42:15

vicente.botet wrote:
> Hi,
<snip>
> I have modified the convert_to implementation with your suggestions (see below) and now we can do:
> 
>     B b;
>    
>     A a1 (convert_to(b, type_tag<A>() ));
> 
> The user can add overloading on the namespace of the class From, or specialize the boost::conversion::convert_to function.
> 
> I have defined the tag with a defaulted parameter value type_tag<Target> tag=type_tag<Target>(), so we can also do
> 
>     A a1 (convert_to<A>(b));
> 
> I have added still an overloading to simplify some uses as
> 
>     a = convert_to(b, a);
> 
> The Target parameter is not used other than to retrieve the type.
> 
>     template <typename Target, typename Source>
>     Target convert_to(Source const& from, Target const&);
> 
> What do you think? Does this interface satisfy your expectations?
> 
> Best,
> Vicente

That seems to be about what I had in mind originally.  I think wrapping 
the ConvertPolicy (Target::allocator_type in my example) in with the 
Source parameter is a good idea, after some thought.  My only additional 
suggestion (and perhaps I'm thinking about this wrongly) is to provide a 
special pair class for just such purposes.  E.g., a convert_pack or 
conversion_pack or s/pack/pair/, which holds its member objects by 
reference and uses names more descriptive than "first" and "second". 
Wrapping everything up in a std::pair might create ambiguous overloads 
that convert from "actual" std::pair's, and it's also clearer what the 
source information actually consists of.  Essentially, I'd like there to 
be a distinction between the "value information" (e.g., the number the 
object represents) and the "non-value information" (e.g., how the object 
dynamically allocates memory) within the Source.

A couple of days ago John brought up some issues with using ADL exactly 
in this fashion, however.  One suggested solution was to put an 
additional tag in the signature unique to the library implementing the 
conversion.  I don't like this.  I'm not sure how best to determine what 
that tag is suppose to be, and it adds seemingly unnecessary syntactic 
weight to the invocation of convert_to.  It seems that somehow, 2 
implementations of the same conversion operation need to be able to 
coexist.  E.g., if we're converting from type1 in lib1 to type2 in lib2, 
we should prefer the convert_to overload in lib2 over the convert_to 
overload in lib1 (somehow), or vice versa.

- Jeff