Re: [boost] [outcome] High level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-31 20:34:54

On 31/05/2017 17:42, Vicente J. Botet Escriba wrote:
> Le 31/05/2017 à 12:55, Niall Douglas via Boost a écrit :
>> I guess, ultimately, the question to be answered here is how much like
>> std::variant<...> should Outcome and/or Expected be? std::variant<...>
>> doesn't implement completely unchecked observers like optional's
>> operator*(), the best you can get is a nulled pointer observer, no
>> silent reinterpret_cast.
>>
> When I started the Expected proposal Variant was not yet there. I
> believe that we could add the following from variant:
> * visit
> * index
> * get_if/value_if
> * get

Apart from the lack of never empty guarantee (which can be worked
around), there appears to be no good reason to not use std::variant<T,
E> to implement std::expected<T, E>.

Well, apart from poor quality of implementation of std::variant
sometimes. For example, libstdc++'s for GCC 7.1 appears to always use
type erased memory allocation. Which, frankly, is daft in C++ 14 when
you are storing either an int or a std::error_code. I would also assume
that std::bad_alloc can be thrown from libstdc++'s std::variant<> :(

(Dinkumware's std::variant<...> is really nice, optimises beautifully
with an all-trivial-when-possible implementation, well done on them)

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/