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.
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
Thank you for the report Gordon. 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