Re: [boost] Outcome/expected/etc/etc/etc

Subject: Re: [boost] Outcome/expected/etc/etc/etc
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-05 14:23:54

On Mon, Jun 5, 2017 at 7:57 AM, Peter Dimov via Boost
<boost_at_[hidden]> wrote:
> Gottlob Frege wrote:
>
>> Some days I'm like "man just accept empty, it would be a simple API", but
>> then I think "it is stupid for variant<int, double> to be empty". Other days
>> I think "just double buffer when necessary" (I assume that's your direction
>> Peter?), but then I think "I don't want double-buffering variant<list,
>> vector> to go on/off based on whether I use MS std vs libc++ etc" and also
>> "I don't want double buffering for cases that only happen in theory, not in
>> practice".
>
>
> That is my direction, yes. My variant uses double storage when (1) not all
> types have noexcept move constructors and (2) there isn't a noexcept default
> constructible type in the list.
>

So converting a Circle to a Triangle might result in a Rectangle,
because Rectangle is the fallback?
I'd rather have double buffering or valueless_by_exception.  ie
correctness or acknowledgement of error.  Not silent incorrectness.

> I think that in practice few variants will hit the double case, as it's rare
> to have variant<list, vector> without a scalar alternative, although who
> knows.
>
> For variant<list, vector> specifically, when going from libstdc++ to MS STL
> the difference is that sizeof(variant) changes, but it changes for
> std::variant, too. Obviously, double storage can never be as good as single
> storage, but I view this as an acceptable compromise. You can guarantee
> single storage by putting a nothrow default constructible type in the list
> of alternatives.
>
>> - I think std::expected should always throw something deriving from
>> std::exception.  So if E derives from std::exception, we can throw it. If E
>> is exception_ptr we can (re)throw it. If E is error_code/system_error/etc we
>> can figure out what to throw.  If E is user-type, then we wrap it in
>> bad_expected or whatever.
>
>
> My suggested expected<> just calls `throw_on_unexpected(e)` unqualified
> (it's a customization point.) There are overloads for std::error_code and
> std::exception_ptr and the fallback default is to throw
> bad_expected_access<E>.
>

Why not add "throw E if derived from std::exception" as part of that
fallback?  It is probably what users want.(?)

Tony