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