Vladimir Batov <vbatov <at> people.net.au> writes:
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.
Thought about it some more while sitting through my daughter's soiree. I am afraid that idea technically will be difficult (and I actually mean impossible) to implement as I feel Target-type-less converter loses all its configure-ability power, value and purpose. That way we are one step from getting away without a converter altogether. That way all configuration parameters need to be provided at the time of the call: T convert<T>::from(Source const&, boost::parameter-list) or T convert_to(Source const&, (boost::parameter-list), Rob's-inference-killer-sentinel) Then, still the question of the return type remains -- returning simply T does not cut it for me. I need two things returned -- the value (conversion result or fallback) and success/failure. Unless we are prepared to discard my major use-case altogether (which would not be nice) we seem to have to have convert<T>::result convert<T>::from(...) or std::pair<optional<T>, bool> convert_to<T>(...) which some people reject considering outright and won't settle on anything like: template<class T> foo(T const&) int v = convert_to<int>(...) foo(v); // call with proper template resolution or template<class T> foo(T const&) foo(convert_to<int>(...).value()); // call with proper template resolution Then we seem back to square one. :-( V.