Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-15 21:19:14

> I know that, which is why I'd prefer the removal to proceed to its
> logical conclusion. :-)
> 
>> Are you referring to .get() and .value()?
> 
> Not just that; is_ready, get_or, set_*, op->, op*, get_error, get_error_or.

I'll accept the .is_ready(), .get_or(), get_error_or(). Logged to
https://github.com/ned14/boost.outcome/issues/19

The op-> and op* are present in expected and optional. I dislike their
reinterpret_cast semantics as much as you do, but if I removed them end
users would complain.

The set_*() functions save considerable typing and boilerplate.

The .get_error() and .get_exception() I may do the same thing as I have
proposed for .get() whereby they mean "do the same default actions as
the non-get edition, but don't return reference to state". I'd love to
know reviewers' opinion on that, including whether to mark the non-get
function with [[nodiscard]].

>> > I'd even remove value_or, there's nothing wrong with r? r.value(): def.
>>
>> Both optional and expected have .value_or().
> 
> Yeah, they are also wrong in having it. You/we don't need to copy
> std::optional. It's not a good example to follow.

I think such convenience member functions harmless, apart possibly from
increasing cognitive load. And users don't have to use them if they
don't want to.

But again, I'd be interested to see how many others think .value_or()
needs to die, and similarly for .error_or() and .exception_or().

>> Alas Expected and Outcome permit usage with types with no default
>> constructor, no copy nor move.
> 
> This would rely on guaranteed return value elision and return {
> in_place, args... }, I suppose?

We don't need to depend on guaranteed return value elision. There is an
emplacing constructor, an initializer_list constructor, and the
observers return references. So one does not need a default constructor,
nor copy nor move.

> If these classes at some point enter the standard, the committee will
> inevitably adorn them with all this beauty, but until then, no need to
> prematurely do that ourselves.

I have no intent for any of the Outcome refinements to enter the
standard. Expected is plenty enough for the standard as a primitive
which can be built upon and extended. I deliberately have made sure that
a result<T> is commensurate to an expected<T> so AFIO v2, if it ever
goes to be standardised, can be based around expected<T>.

I do intend to submit Outcome for SG14's collection of low latency
libraries in the non-standards-proposal category.

>> BTW, is everyone aware that expected<void, void> is legal?
> 
> I wasn't aware that E could be void. Which reminds me to ask you, do you
> really drop the value on the floor when converting from <T> to <void>?
> This seems like something to avoid. The value is probably important.

You cannot convert, even explicitly, from any Outcome-y <T> transport to
a <void> transport. It's disallowed because it causes data loss.

You must either manually extract and repack the E into a new <void>
transport, or there is a free function as_void() which will do it for
you. The latter should produce tighter code and compile faster, it uses
special magic type sugar to bypass implementation as
BOOST_OUTCOME_TRY(v, expr) always returns a void converted edition of
expression, and in real world usage you will using a lot of
BOOST_OUTCOME_TRY(v, expr) so it needs to be light on compile times.

BTW I leave for a business trip other side of the country tomorrow and
Wednesday. Expect no replies here until Thursday.

Niall

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