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

Subject: Re: [boost] Outcome/expected/etc/etc/etc
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-05 14:35:45

Le 05/06/2017 à 13:57, Peter Dimov via Boost a écrit :
> 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.
Alternatively, we could as well add a phantom type that says, please, 
use double buffering if absolutely needed.
>
>> - 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>. 

The current proposal (not necessary accepted) throw always 
bad_expected_access. If we can throw different exceptions, I believe 
that we should have as well a type_trait that gives the exception thrown 
by an error. This could be useful for generic code. I have not a 
concrete use case in mind yet.

Vicente