On May 10, 2011, at 3:10 AM, Vladimir Batov wrote:
From: "Vicente BOTET" <vicente.botet@wanadoo.fr>
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