Re: [boost] [Review] Boost.Convert library, last day

Subject: Re: [boost] [Review] Boost.Convert library, last day
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-05-03 16:05:41

This is not a review.  I may write a review later, but don't wait for
it.  I do however, have serious concerns about some aspects of the
convert library which I would like to raise.

On the subject of the "multi-purpose" function:

Personally, I feel (as some others have suggested) that returning an
object convertible to the "real" result type is dangerous.  I am a heavy
user of "auto" these days, and I would like to be able to write

auto i = convert<long_type_name>::from(s);

or similar things without worrying about the "surprising" result type.

However, it would be easy to write a wrapper function to facilitate this
use case if necessary, so I don't consider it a critical issue.

I have a much bigger concern with the detailed semantics of the
conversion function.

One of the big issues (IMHO) with lexical_cast is the potentially
surprising behaviour that can occur when the global locale is set to
something other than the classic locale.  It is good that convert offers
the locale_ option to override the locale used for conversion, but I
didn't see anywhere in the docs a clear explanation of what locale is
used when none is specified.  Is it the global locale or the classic
locale?  This needs to be mentioned clearly and conspicuously.

My preference would be that the classic locale is always used unless
another is specified.  That allows convert to be safely used in library
code that cannot know the global locale without surprises.  It also
allows "optimized" implementations such as that you are suggesting for
string-to-bool to be inserted without changing the existing interface.

The suggestion in another post that the optimized string-to-bool
implementation should try "true", etc. and then fall back on a localized
conversion (or, worse, that it should not support the localized
conversion at all) concerns me greatly.  This optimization is then
changing the behaviour in non-English locales, since they will now
accept "true" where before they did not.  If you intend to perform this
kind of breaking change in the development of Boost.Convert, then that
fact also needs to be made clear and conspicuous in the documentation.

Finally, I am concerned by the prospect of ODR violations as a result of
specialised conversions.  Taking again the string-to-bool conversion as
an example: if part of a program is compiled with this optimized
implementation present, and part is compiled with it absent, then I
suspect the program will be in violation of the ODR.  This seems really
quite dangerous.  In particular, I see no safe way for me to write an
optimized or otherwise customized implementation of any conversion
unless either

(a) it is distributed as part of Boost.Convert, and included
unconditionally whenever the definition of convert is, or

(b) it converts to or from a type A, and is included unconditionally
whenever the definition of A is.

Is the extension facility intended to be used in these limited
circumstances?  If so, then that fact must also be clearly and
conspicuously documented.  If not, then I would like to know how ODR
violations are to be avoided.

John Bytheway