Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-04 15:20:48

On 5/4/2011 2:01 PM, Stewart, Robert wrote:
>>> convert_cast(s, 17) has the same problem and breaks with the
>>> new-style cast pattern.
>>
>> What is the breaking aspect?
>
> New-style casts are of the form xxx_cast<T>(S).  Thus, that has to be convert_cast<int>(s, 17) to fit.
This is a special case of the discussion below.

>>> The target type should be required in all cases, I suspect,
>>> to make things clearer:
>>>
>>> try_convert_to<int>(s, i) clearly indicates that int is the
>>> target type.
>>
>> Yes, but thanks to type inference users are free to write
>> try_convert_to(s, i) instead and that's even worse than
>> try_convert(s, i). :)
>
> You can make the second argument non-deducible thus requiring the target type.
I didn't know that was possible. How? If the target is non-deducible then I agree the _to suffix for 
optional_convert and try_convert is good.

Back to something you said earlier:
>>> If others agree, I could also go with Vincente's version of
>>> try_convert. It doesn't bother me that passing in the variable
>>> by reference makes it a two-liner, since the expression itself
>>> can go inside the if statement and it implicitly supports
>>> non-default-constructable types.
> It is certainly non-surprising.
>
> Using Vicente's default_value customization point still makes convert_cast<optional<T>> a viable candidate:
>
> auto const c(convert_cast<optional<int>>(s));
> if (c)
> {
>    // use c.get()
> }

What about UDT specializations for casting to and from optional<T> (i.e. string<->optional<int> 
where 'n/a' could be the unset string)?

-Matt