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

Subject: Re: [boost] Outcome/expected/etc/etc/etc
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-05 11:57:20

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.

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>.