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: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2009-10-24 17:39:39

vicente.botet wrote:
> ----- Original Message ----- From: "Jeffrey Hellrung"
> <jhellrung_at_[hidden]> To: <boost_at_[hidden]> Sent: Friday,
>> 2) Assuming I understand the Conversion library correctly, what are
>> the advantages to using both overloading via ADL and function
>> template specialization as opposed to just the former?  I'm not
>> familiar of any other free functions used in boost (or anywhere
>> else, for that matter) that rely on (perhaps I should say "allow"?)
>> function template specialization, so I'm wondering what the
>> motivation and pros/cons are (cons other than compiler support).  I
>> would guess that function template specializations must reside in
>> the same namespace as the primary template...?
> 
> The single think I can answer is that the same question is already on
> the documentation,  unfortuantley with no answer. The answer I can
> give you now is that I don't master ADL to the point of using it to
> imlement what I have in mind. I'm unable to saying you if this is
> possible or not. The question of using partial specializations of
> template functions is for the moment secondary,

There's no such thing as a partial specialization of a function
template.  Only classes may be partially specialized.  You can
explicitly specialize a function template (i.e. give specific values for
all of its template parameters); is that what you mean?

> if there is a better
> way to achieve the same goal. My  main concern is if we need the
> generic functions convert_to and assign_to. If this can be
> implemented in a better way using only ADL, we could do this way. Of
> course I'm intersted in knowing how this can be implemented using
> only ADL, even if this is evident for most of you.
> 
>> This is definitely a problem that needs to be solved (correctly) in
>> a generic fashion, so I'll try to follow your progress.
> 
> I'm open to any sugestion. If we can implement it using only ADL, I
> will do it once I'll know how.

To do what you want with ADL has two problems:

1. You would have to call convert_to without passing any template
arguments, so the destination type would have to be deducible from the
arguments.  You can use something like the type_tag Jeff mentioned.

2. The conversion function from A to B would have to be defined in
either the namespace of A or of B (or of something else involved, e.g.
the type_tag).  If converting between types both from libraries you are
not writing it is unwise to declare functions in their namespaces.  If
the library author decides to add support in the future with the same
name (something I guess you're hoping for, if this name convert_to
becomes widespread) then it will clash with your definition.

But even if you avoid polluting other people's namespaces you will
suffer a similar problem if they add a convert_to overload doing the
same thing as yours; you'll get an ambiguous function call where you're
using it.

Worse still is if two people add convert_to overloads in the same
namespace between the same types in such a way that the compiler doesn't
see them both and complain; then you have an ODR violation and risk
undefined behaviour (but you'll probably get away with a linking error).

Similar issues apply even if you don't use ADL.

The only ways I see to reliably avoid these sorts of problems are:

1. Whenever you want a conversion function between two types, get the
author of a library containing one to add it to that library (and make
sure the author of the other one doesn't add it to his).  I presume this
is impractical.

2. Somehow tag all the overloads and uses of convert_to in one library
with a type from that library such that they will never clash with
overloads from other libraries.  The tag can facilitate ADL too.  (This
is a different tag from the type_tag above).  This will add notational
inconvenience and make it harder to use convert_to generically (e.g. as
in your std::pair example; it will only work if there are convert_to
overloads for both types in the pair with the same tag).

> BTW, can we add functions on the 'std' namespace?

No, you may not.

John Bytheway