Re: [boost] expected/result/etc

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
std::pair<void*,error_enum>.

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?