Boost logo

Boost :

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-31 16:42:31


Le 31/05/2017 à 12:55, Niall Douglas via Boost a écrit :
>> Returning a pointer actually only superficially looks like you are
>> protecting yourself from the narrow contract. You just force the caller to
>> use narrow contract function on the pointer.
>> This reminds me that at some point people here in Boost discussed that
>> get<T>() accessor on variant<T, U, V> should return optional<T&>.
> What the C++ 17 standard eventually did was to add a
> std::get_if<I>(&variant) which returns a pointer to the value if the
> variant is in that state. std::get<I>(variant) throws an exception if
> you don't use the right state.
Hrr, I believe that it had a narrow contract.
We have holds_alternative and index. When you know this you don't need a
wide contract.
I'll ask in std-discussion why we don't have a narrow access. Is it
because we want to favor visit?
> 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

If we reach to have a SumType [1] we could as well define
* sum_type::size and
* sum_type::alternative,

Vicente

[1]
https://github.com/viboes/std-make/tree/master/include/experimental/fundamental/v3/sum_type


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk