Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-05-10 07:48:23

On May 10, 2011, at 3:10 AM, Vladimir Batov wrote:

>> From: "Vicente BOTET" <vicente.botet_at_[hidden]>
>>> De : "Vladimir Batov"
>>> 
>>> I am not sure why that distinction has to be made. Now that converters are gone
>>> and all parameters are provided in one call, the implementer knows what
>>> conversion is needed. That is, if there are no 'format_' parameters specified,
>>> then, say, spirit-based quick conversion is applied. As soon as I see 'format_',
>>> then I fall back to stream-based. So, all we seem to need is convert::to.
>> 
>> Vladimir, what is the default behavior of your convert::to proposal with only one
>> source argument?
>> If it is a call to the conversion operator then the two approaches are just differing
>> at the interface level and we should have just one. If the default behavior is the
>> equivalent of a lexical cast whatever technique is used, the the libraries have
>> different semantics and I need to have the Boost.Conversion default behavior.
>> So we will need two libraries.
> 
> Err, you mean int i = convert::to<int>(str); right? Does not it work as lexical_cast (for string-to-int) as I do not think there are other choices. I am not sure what "a call to the conversion operator" means. If see this call returning int() or some default_value<int>, then I firmly believe that is not right as you cannot possibly anticipate what the user might consider an appropriate default.

I am not sure if one unified function is possible, but I wonder if one way to define a "best conversion" function, would be to drop lexical_cast's type-to-stream-to-type default, which is IMHO what really messes up thinking about type-to-type and string-to-type/type-to-string in the same sentence.

And so convert_cast<T>(S) would use something like Convert if S or T is string (with any behavior determined by arguments), and something like Conversion if neither is.  

[again i'm not concerned with the name just the syntax/semantics.]

This is also in line with Antony Polukhin's improvements for lexical_cast which are mostly not lexical IIUC.  I think people and their metaprograms expect a conversion function that is not actually lexical unless S or T is string.

IMO the name and default-to-streaming behavior of lexical_cast makes plenty of sense for string-to-type or type-to-string, but would rarely be useful for type-to-type.  

I'm not sure if I have followed the entire conversation (I've read it once), but I do not see anything that is incompatible about Vladimir's and Vicente's approaches unless this misfeature of lexical_cast is preserved.  There are some extra arguments (e.g. manipulators) which might become legal depending upon S or T, which Vicente does not think he needs for any other type-to-type.  There is a need to somehow return a value along with a success flag, or to return an optional.  There is a fallback.  

Cheers,
Gordon