Boost logo

Boost :

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-01 20:23:54


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


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