Subject: Re: [boost] [review] string convert
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-05-04 10:39:01
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