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
> 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
> 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
> 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
Why not add "throw E if derived from std::exception" as part of that
fallback? It is probably what users want.(?)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk