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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-05-01 18:29:25

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'
...
if (ob == false) // true (I think) as optional<T>==(T) is used
...

so bool(ob) != (ob == true).

(
Or if I misunderstand the ordering of conversion-to-bool vs operator==, or
optional<bool>::operator==(bool) was explicitly disallowed, 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)

Tony