On May 4, 2011, at 9:57 AM, Matt Chambers wrote:
I definitely could do without the tags to pick an overload. I'd much rather have the try_ prefix. So:
int i = convert_cast<int>(s); // default behavior: might throw int i = convert_cast<int>(s, 17); // won't throw; can't tell if conversion successful; but how often do people actually care about that if they're providing a fallback value? it's still very practical and useful! optional<int> i = try_convert_cast<int>(s); // won't throw; specialized version of optional is not necessary since there's no fallback value
Yep, not bad.
convert<int>::result i = try_convert_cast<int>(s, 17); // won't throw; specialized version of optional is necessary to detect failure
No, no special optional thing is needed. Please reread my 8:35am reply to Vladimir. Sorry, it's a pair<bool, int>. Why do people hate pair? There's a boolean and a value, why is that not a pair? The returned value is not optional in this case.
// I'd get rid of these: //int i = convert_cast<int>(s, 17, throw_even_though_i_specified_a_failback_); // what's the purpose of this overload?
This is the nondefaultable case where you still want it to throw.
//optional<int> i = try_convert_cast<int>(s, 17); // this doesn't allow checking for failure, so there's not much point
Again, it's for nondefaultable types. You need to supply a value, but you wouldn't actually use it if conversion failed.
//pair<bool,int> i = convert_cast<int>(s, 17, fallback_and_report_success_); // it's burning my eyes
Hahaha. Again, this is replaced by your try_convert_cast<int>(s, 17) and you could call it something else but it's really a pair. So you get rid of two tags by adding one new function name. Sounds good to me. On May 4, 2011, at 9:57 AM, Matt Chambers wrote:
Finding the right prefix for "_cast" will be a challenge. Sigh, another naming debate. (Naming is important but so difficult!) It does seem like the direction that *_cast<>() is clearer to people than convert<>()
I also like as<>() :-) but somehow I don't think that'll generate consensus. The first overload is a drop-in replacement for lexical_cast as far as I'm concerned (even with additional arguments for locale and manipulators). If it can pass all the lexical_cast tests, what's the harm?
I don't see any harm. Lexical Cast just needs a new maintainer who's willing to implement this stuff, against the intentions of the original author. IMO things do change. Cheers, Gordon