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

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 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/