Hi Vicente, all, I had hoped that Vladimir Batov, author of Boost.Convert reviewed earlier this year, would contribute an "informal review". Instead I hope he doesn't mind if I quote some correspondence he sent off-list, and perhaps get him to join us. (I normally would never quote off-list communication on-list, but I don't see how a review manager can use off-list contributions without quoting them, if there's no request for anonymity. I hope Vladimir agrees that I've been judicious. ;) On Aug 1, 2011, at 8:47 PM, Vladimir Batov wrote:
On the conceptual level it is far from clear to me if such a framework is needed to begin with. In the Scope section Vicente explicitly states that his library "is not particularly concerned with cases of...". Those "excluded" cases happen to be the most tricky/used/needed cases. With those string-to-type, etc. cases taken out of the picture from the set-go, the usefulness of the remainder was many times questioned during Convert discussions (well before the Convert review) ... I never had a need for such a generic type-to-type conversion framework. Obviously, it's my own limited experience and it can be vastly different for others.
Secondly, on the implementation level I raised a few concerns in our conversations with Vicente about his library ... I do not feel Vicente's implementation is sufficiently generic. In particular, I am under strong impression that having Target and Source together as in
template< class Target, class Source > Target explicit_convert_to( Source const & u );
does not really work on a bigger scale. That does indeed work for *concrete* Target and Source types. However, when one tries to generalize (partially specialize) for a range of similar types, then I feel the framework easily falters. Namely, if I decide to specialize the above for a range of related Target types (say, string-related types) *and* separately specialize for a range of related Source types. Then compilation will fail if these two separate specializations happen to overlap for some Target-Source pair. That is not an academic case but concrete issues I faced with Convert. I'd expect it to be as relevant with Vicente's library.
I agree that it will take some careful shepherding to define a set of conversions without ambiguous overloads, which might be tricky to avoid if you're working with converters written by other people. Vicente, do you have any solutions for this? Cheers, Gordon