Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-05-06 19:34:52

> From: "Matt Chambers" <matt.chambers42_at_[hidden]>
> ...
> Your examples are hypocritical based on your earlier argument about there 
> not being a meaningful default value for your non-defaultable types. We 
> agreed there is no meaningful default for the "to_be or not_to_be" 
> problem, so your usage here of defaulting it to to_be doesn't make sense. 
> Especially when you proceed to use the return value that's invalid...

Well, indeed I am such a hypocrite. :-P

On the serious note though I feel we are going in circles. We've discussed 
that before. Thare are, in fact, two different use-cases:

1. the relevant class is not DefaultConstructible;
2. the relevant class does not have meaningful fallback.

These two cases are *separate*.

> Especially when you proceed to use the return value that's invalid...

That's incorrect. I proceeded to use the value of *my choice* after I found 
out the conversion failed. Consider the following tedious code doing the 
same:

optional<hamlet_problem> t = optional_convert_to<hamlet_problem>(s);

if (!t)
{
    message("Invalid input. Using fallback");
    t = to_be;
}

With "t = to_be" I *choose* to use a certain value because I have to choose 
something to keep application operational.

> If a default value makes sense, then you use:
> hamlet_problem t = to_be;
> if (!try_convert_to<hamlet_problem>(s, t))
> {
>   message("Invalid input. Using fallback");
> }
>
> It's briefer than your version.

Yes, indeed, it is an alternative. My problem with it (and I repeat it's 
*my* problem) is that it uses modifiable by-reference argument passing which 
I personally quite dislike. Secondly I cannot pass the result of 
try_convert_to() to another function which could evaluate the success and do 
something with the value. But to be honest the second "argument" is smoke 
and mirrors -- I just can't stand modifiable by-reference arguments. :-)

> The same goes for your direction class. We really need more context to 
> understand your use case and why either the optional<T> 
> optional_convert_to (without a fallback/default provided, because the 
> value isn't needed if it fails) or try_convert_to doesn't work for you. I 
> know your argument about the output by reference, but that is merely an 
> interface concern which other participants here haven't yet shared.

I am pretty sure I covered all relevant use-cases in the 'convert' 
documentation. If you feel you've covered them all with the interface of 
your choice, then that's great. If that's accepted into Boost, I'll gladly 
use it rather that maintaining mine. That's a promise.

V.