Re: [boost] [review] string convert

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