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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-02 10:33:43

Le 02/05/13 16:17, Gottlob Frege a écrit :
> On Wed, May 1, 2013 at 8:23 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>> Le 02/05/13 00:29, Gottlob Frege a écrit :
>>
>> 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.
>>
> You of course could, but I think std-proposal and the committee has
> probably had enough of optional for a while.  I think the next best step is
> a paper clearly showing all the issues and offering clear
> recommendations/options.
>
>
>> 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?
>>
>>
> I don't think it should be different from optional.
>
> But expected *is* different than optional - look at the name.  You could
> argue that "expected" implies that you really did expect the value to be
> there, so implicit conversion would not be, well, unexpected.  Whereas
> optional means the value is optional - being disengaged is just as expected
> as being engaged, thus implicit conversion of optional might not be as
> expected.
>
> But overall, I think the consistency is more important.
>
> You could also argue that optional should have implicit conversion, since
> it has already started down the road of "act like T" via things like the
> mixed relational operators.
> But I worry about implicit conversions (in general) and I'd rather not
> bring up any changes to optional that are just design decisions (vs issues
> of incompleteness or "unintended consequences").
>
> So overall I _lean_ towards no implicit conversion, but I can see both
> sides of it.
>
>
+1
Vicente