Re: [boost] [convert] no-throw and fallback feature

Subject: Re: [boost] [convert] no-throw and fallback feature
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-05-11 13:19:20

On May 11, 2011, at 7:08 AM, Stewart, Robert wrote:
> Also, assignment within a conditional is error prone, so often rejected.  An idiom that relies on it, even though not a normal assignment, will likely also be rejected.

I'm very sorry to hear that.  I hope not!  

I guess we should consider what opt_tie(i) == convert_cast<..>(...) would mean.  Obviously it would fail in the simple impl I posted.  If it did work, it wouldn't buy you anything above constructing an ordinary optional<T>.

On May 11, 2011, at 7:46 AM, Stewart, Robert wrote:
> Gordon Woodhull wrote:
>> On May 10, 2011, at 3:55 PM, Vicente BOTET wrote:
>> 
>> I think opt_tie should behave as if it's optional<T>&.  I am
>> not sure why one would want to chain assignments in this case,
>> but it should be possible.
> 
> If you can't explain why it is needed, I consider that a reason to reject it.
> 
> Since tie() doesn't work that way, it would be surprising.  

From the user's point of view, tie() does work the same.  It returns pair<&,&> which is chain-assignable.  I would expect an assignment operator to return something convertable to T, whether that is T& (best), T or T const& (okay).

> However, it would permit Vicente's use case:
> 
> int i(fallback);
> if (!(opt_tie(i) = convert_to<optional<int>>(s))

This is the way I would like to deal with fallbacks when I need to know whether it succeeded.  It's succinct and I think very clear.  It might take a little bit of investigation to understand why it works, but I think it's immediately clear what is supposed to happen.

I am not as happy with try_convert_to (I don't like out-parameters if they can be avoided), but I understand that everyone has their own preferences, which might include avoiding assignment within a conditional.

>> template<typename T>
>> class opt_tie_type {
>>  T &x_;
>> public:
>>  opt_tie_type(T &x) : x_(x) {}
>>  const optional<T> operator=(optional<T> const& y) {
> 
> The return type should be optional<T> const & if not void.

Good point on the reference.  Certainly not void, that would defeat the purpose.

> I don't think anything more optimal is possible after addressing the return type of the assignment operator.  However, a robust implementation will need a PTS for reference types to address the reference-to-reference problem (or use remove_reference).

Good point.  Thanks.  But wait a sec, given that opt_tie_type is a detail of opt_tie(), how is it possible that T is a reference type?

Vicente, do you want to propose this for Boost.Optional?  And what do you think about the overload with extra bool&?  It would require a second opt_tie_type.

Cheers,
Gordon