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: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2017-06-01 14:04:56

On 31 May 2017 at 21:34, Niall Douglas via Boost wrote:

> 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<> :(
>

Huh? Where do you see this?