Boost logo

Boost :

Subject: Re: [boost] expected/result/etc
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2016-01-28 01:49:38

So looking a few of these libraries/proposals I have a few things I'm
interested in.

- Is it at least as good as a simple hand-rolled solution?
- Can you transport error codes through layers without knowing specifics
of an error?

For the second Niall's outcome/result handles very well I think.
std::error_code and std::exception_ptr transport is good enough for
almost any reasonable type agnostic error transport.

If the direct caller can handle the error returning an error enum
instead of a std::error_code will often be better. It looks like the
DXXXXR0 expected proposal allows for this.

A variant is a good implementation for many types.
And I think clearly the right default behavior.
However, I'm not convinced that a variant is always the best implementation.

Take for example an expected<void*,error_enum>.
Although I haven't done tests I'd be reasonable confident returning this
by value would perform worse than returning

First, the machinery is going to make it store an extra byte at least
for the variant discriminator.

Then, you likely branch before the copy (maybe optimized away by a smart
variant implementation).

In fact in *most* cases of returning a pointer and error_enum you should
be able to get away with returning a the equivalent of
union { void*, error_enum }
As *most* error_enums are relatively small and have values smaller than
any valid heap or stack pointer.
It would be nice to be able to opt in for this.

More generally given
  - an error_enum with an OK or 'not an error' value
  - a T that is cheap to default construct and cheap to copy/move
Is the library solution better than returning a pair<T, error_enum>?
Or a function returning an error_enum with an out param?

Boost list run by bdawes at, gregod at, cpdaniel at, john at