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

Subject: Re: [boost] [Review] Boost.Convert library, last day
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-05-03 06:41:44

> Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes:
> ...

Hartmut,

Thank you for your review. Much appreciated. Please let me address a few points
that you mention that I personally find incorrect or have to disagree with.

> From reading the docs I came away puzzled. It was highly confusing to me to
> have the convert::from<> return different things in different contexts. 

I was under impression that from the user perspective convert::from returns
either the converted value or convert::result in all contexts. If users "really
just want to do the conversion without spending much time reading the docs",
then they'll use 

int i = convert<int>::from(string)

as described in "Getting Started" without even knowing there is convert::result.
Hardly puzzling and confusing.

> As Thomas Heller pointed out, the existence of several default conversion
> paths for the result type will (with high probability) create havoc for
> users who really just want to do the conversion without spending much time
> reading the docs. 

I am surprised you are using users not "reading the docs" as an argument. I find
such argument quite unfortunate especially from the developer of such a complex
library as Spirit.

Secondly, I am not sure about "existence of several default conversion paths for
the result type". Again, the only types convert::from result is converted to are
the Target type and the convert::result type. Both types are for different uses
and are described in the docs. As for Thomas Heller's doomsday predictions, then
it must be so if he says so. Or may be not. I do not see it that way anyway.

> The current implementation of lexical_cast (even if is not
> always the fastest), appeals to many people because 'it just works'. Any
> conversion library needs to be similarly resilient to be useful.

I am not sure if you can count my (and my colleagues) experience who've been
using convert for about 3-4 years. It just works. Admittedly, our usage patterns
are largely close to lexical_cast. Like

int i = convert<int>::from(str, INT_MAX);
if (i == INT_MAX) message("ignored");
proceed using 'i'.

Indeed, there were some use-cases mentioned which I've never come across. I am
not convinced that is because 'convert' is flawed. I suspect that is because
those use-cases are of more of academic rather than practical value and so far I
do not remember seeing anything I would not be able to address.

> It is a natural extension of lexical_cast's functionality and for
> this reason should be merged with lexical_cast instead of being accepted as
> a separate library. Having two stream based conversion libraries in Boost
> (which moreover while complementing each other, sometimes expose different
> behavior) does not make any sense to me. 

I am not sure if I ever mentioned why convert is not a "natural extension of
lexical_cast". :-) More so, it might have started as such but at this point I do
not see 'convert' as an extension of lexical_cast. If it is so, then similarly a
car would be a natural extension of a wooden cart. Should we abandon car
development and try fitting an engine on to a cart instead?

As for stream-based conversions, then I chose those because it was easier to get
proof-of-concept working. Then, I was satisfied with its features and
performance so I never needed to replace that. I believe long time ago we agreed
that providing Spirit-based string-to-int converter though convert API would be
sensible for those who needed it.

> OTOH, the functionality exposed by convert is much needed and has to make it
> into Boost somehow.

Yes, that seems to have been the common approach of 'no' votes. Like, yes, we
need the functionality. No, the proposal is bad or not good enough (for one
reason or another). We need to do it differently. I'd be happy if someone else
could step forward and propose something wonderful, commit to it and deliver.
Any serious and committed/responsible takers? Any time frames? 

V.