Re: [boost] [outcome] To variant, or not to variant?

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-31 20:24:27

On 31/05/2017 15:26, Peter Dimov via Boost wrote:
> Proposed additional narrow:
> 
>    // nullptr when !has_value(), otherwise &value_
>    T* operator->() noexcept;
>    T const* operator->() const noexcept;
> 
>    // *operator->()
>    T& operator() & noexcept;
>    T const& operator() const & noexcept;
>    T&& operator() && noexcept;
>    T const&& operator() const && noexcept;
> 
> 
> value() can also have the four-overload form, not shown for brevity.
> 
> Is there anyone that objects to that model?

I don't mind those operators being wide. I do object to them being
narrow as it's too little typing.

> I am sympathetic to people's desire to have a statically checkable value
> accessor, but I see no reason to provide such for error() or exception().

I would assume that if the programmer writes .error_raw() on a valued
object, they'd like to see a compiler warning.

> The "exactly one is true" requirement allows all possible checks to be
> expressed in a concise manner. If you want to test for error or
> exception, say, that's !has_value.

Such a design would not allow identical code to work correctly with an
empty-capable or non-empty-capable objects.

It should be very simple, even simpler than yours:

.empty() true => object is empty
.has_value() true => value() observes a T
.has_error() true => error() returns the error code
.has_exception() true => exception() returns an exception_ptr to what
would be thrown if you called .value()

Niall

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