Re: [boost] Boost.Conversion - pre review request

Subject: Re: [boost] Boost.Conversion - pre review request
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-07-10 19:17:09

On Jul 9, 2011, at 11:39 AM, Vicente Botet wrote:

> You are right and the same applies to any type-to-type conversion. And maybe
> this is the MAJOR flaw of Boost.Conversion: to think that we can define
> extrinsically THE conversion between two types. Every body admit that if a
> class T defines a constructor from a std::string THE conversion from
> std::string to T is the one defined by this constructor. 

Yes, this is a problem with all global customization points.

I would expect than any one developer would want to use either lexical_cast or coerce.  However, does the ODR mean that the exact same conversions would have to be defined in a library and in any code that uses the library?  That sounds tricky!

Just document it as a known limitation and reviewers can decide 

> Note that this issue is not only limited to Boost.Conversion but to any
> function that could be overloaded by the user or any template class that can
> be specialized by the user. Two different parts of a program could make the
> same overloading or the same specialization. This doesn't implies that we
> should avoid overloading or specializations.

Right.

> It seems clear to me that if we don't have a consensus on the default
> type-to-type conversion extrinsically Boost.Conversion mustn't not provide
> it,

IIUC it's providing the conversions and the user chooses them by #including the headers of interest.

> neither the user.

?  Really?

> Does it means that Boost.Conversion has no sens? I
> don't know. 
> 
> Coming back to the string to int conversion, if we can not have a default
> string-to-type or type-to-string, Boost.Conversion must remove these
> specializations.

Seems to me there are still defaults: decimal provided by either lexical_cast or coerce depending on user preferences.  And the user has to be careful.  

Or are you saying that since all libraries linked into a program must agree on which conversions to use, Conversion should only define ones that everyone agrees on?  That sounds rather extreme.  Why not just stipulate that the set must be the same throughout the program?  Libraries would document or allow customization of which converters they use.