Re: [boost] [gsoc-2013] Boost.Expected

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-05-02 05:05:45

On 05/02/2013 02:23 AM, Vicente J. Botet Escriba wrote:
> Le 02/05/13 00:29, Gottlob Frege a écrit :
>> On Wed, May 1, 2013 at 5:33 PM, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]> wrote:
>>
>>> Le 01/05/13 18:27, TONGARI a écrit :
>>>
>>>   I didn't follow this thread closely, but have you consider an implicit
>>>> convert operator to value_type? e.g.
>>>>
>>>>       expected<SomeType> f();
>>>>
>>>>       SomeType var = f(); // throws on error
>>>>
>>>> It's most intuitive to me.
>>>>
>>>>
>>>>
>>> We need to choose between an explicit conversion to bool and an implicit
>>> (or explict) conversion to value_type,  otherwise there would be a
>>> conflict
>>> when the value_type is bool. I prefer particularly the explicit bool
>>> conversion. This is in line with the optional design.
>>> BTW, the following is not so ugly.
>>>
>>>      SomeType var = f().value(); // throws on error
>>>
>>>
>>> Best,
>>> Vicente
>>>
>>
>> Let's not use optional as the pinnacle of design just yet.
>> optional<bool>
>> in particular.  I'm concerned about:
>>
>> optional<bool> ob = false;
>>
>> if (ob) // true, as optional is 'engaged'
> This as I understand it.
>> ...
>> if (ob == false) // true (I think) as optional<T>==(T) is used
>> ...
>>
>> so bool(ob) != (ob == true).
> Hrr, this is really surprising.
>
> I guess the pragmatic solution is to remove also the explicit conversion
> to bool and use an explicit valid() function
>
> if (ob) // compile fail
>
> if (ob.valid()) // true, as optional is 'engaged'
>
> if (ob == true) // true as optional<T>==(T) is used
>
> The same seems to be applicable to expected.
>> (
>> Or if I misunderstand the ordering of conversion-to-bool vs
>> operator==, or
>> optional<bool>::operator==(bool) was explicitly disallowed,
> I don't see nothing in http://isocpp.org/files/papers/N3672.html
>
>> then you would
>> have a problem with optional in generic contexts:
>>
>> optional<SomeType> opt = ...;
>>
>> if (opt == SomeType(val))
>> ...
>>
>> does this behave differently when SomeType == bool vs SomeType == int?
>> )
>>
>>
>> I suspect both optional<bool> and expected<bool> will be somewhat common
>> uses (considering the number of tri-bool classes in existence), so I
>> think
>> this is a real problem that we need to resolve.  (And I expect to
>> write up
>> something after BoostCon/C++Now)
>>
> Agreed. I could try the std-proposal forum or c++std-lib-ext_at_[hidden] if
> you don't mind.
>
> Coming back to the OP, expected is a type to avoid to throw exceptions.
> It would be surprising to me that an exception could be thrown by an
> implicit conversion.
>
> Are there others that think that implicit conversion to ValueType is a
> good thing to have?
> What makes expected so different from optional to have a different design?
>
>
> Vicente
>
>
An expected is just a optional which have an error status when 
disengage. If expected is standardized in the future, it would be best 
to keep the same behaviour with the implicit/explicit cast as optional. 
Otherwise, I'm pretty sure it would lead to frustrating error from users 
using both.

Pierre T.