Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk