Scott McMurray <me22.ca+boost <at> gmail.com> writes: ... I really like the split into two parts, to allow a direction word.
If you don't like the ::from, what about something like this? foo(convert(x).to<int>()); optional<int> i = convert(x).to<int>(std::nothrow); // or maybe .try_to<int>()
It's arguably the same as the .value() in Vladimir's lib, except that by delaying providing the type, it makes sense that it's needed.
int foo = convert("123").to<int>(); looks *very* attractive as it allows to have the converter proxy which from my experience (which obviously can be wrong) is essential for any functionality beyond lexical_cast. Still it removes that "excessive" converter exposure that some people have strong objections to. The fallback value and additional configuration (locale, formatting, etc.) could probably be provided with (just thinking out loud): int foo = convert("not int").to<int>(-1); int foo = convert("not int")(format_ = std::hex).to<int>(-1); So, 'convert' returns a Target-type-less converter, right? The only wrinkle I can see so far is that 'convert' now does not know the Target type and, therefore, has to accept/support all configuration parameters (format, locale, etc.) for all Target types even if those configurations do not make sense for that ultimate Target type. It could be quite confusing. The advantage of the original proposal was that the Target type was known much earlier (at the time of converter construction), so non-applicable configurations would not compile/be accepted. Hmm, I am afraid the above might not be implementable. Say, the user wants to supply his own manipulator (or locale). That manipulator obviously has to be attached to something (std::istream). However, we do not have that stream in the converter as the converter cannot possibly know if that stream will be needed. V. V.