Re: [boost] conversion review report

Subject: Re: [boost] conversion review report
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-07-18 02:46:48

Le 16/07/12 22:35, Gordon Woodhull a écrit :
> Hi Vicente, all,
>
> Profuse apologies for the long delay in writing this report.
>
> Cheers,
> Gordon
>
>
> Report on Boost Conversion Library Review, August 20-29, 2011.
>
> I want to thank Vicente Botet Escriba for submitting the Conversion library for review and for his general good nature in receiving criticism and alternate designs.
>
> The Conversion library presents a general framework for plugging in conversion operations between arbitrary types, providing a consistent interface for type-to-type conversions.
>
> The library is unfortunately rejected.  During the review, there were two votes for acceptance and two against, and some interesting conversation from about a dozen participants.
>
Thank you for the report Gordon.
> The major reason the library can't be accepted in its current form is that there was near consensus that there is no universal conversion domain, especially when the source or destination type might be a string.
I recognize that the string conversions are a controversial case. From 
my point of view, we can admit however that we have a "universal" 
conversion domain defined by the implicit/explicit conversion provided 
by the language, which ensures that only one conversion from a source to 
a target can be defined. Maybe the error of the library was to consider 
that the domain could be larger :(
>
> Much of the review focused on possible One Definition Rule (ODR) violations, which are a consequence of having a universal customization point using template specializations or function overloads.  Many solutions were offered, which will make up the second part of this report, "How to Avoid Universality."
IMO the major problem the library has is that it can not ensure there is 
only one conversion and can not report always for multiple ones. That 
means that a project that is able to master it could take advantage of 
the provided framework.

As I said during the review this problem appears on any library that has 
customization points relating two or more types. The example I have in 
mind is Boost.TypeErasure, as IIUC the concept map for a Model (Source) 
as a Concept(Target) has a similar problem, there is no single way to 
map a Model to a Concept and independent 3pp could choose different 
mappings violating ODR. I hope Steve will address this issue better than 
I did and I'm curious to see how the Boost community will consider this 
problem (if it exists, of course).

Last, I would like to thank everyone participating in the review.

Best,
Vicente