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

Niall Douglas wrote:

I know you've read the history page Peter, so you know Outcome has already had its API trimmed by half. These past 18 months I've been removing stuff, paring down to the minimum. I don't claim I'm done removing stuff yet, I agree there is a little more to go, but it's getting harder to decide on what isn't really necessary any more.

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'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've also found the ternary operator a poor substitute for .value_or() in practice because both sides need to be the same type else the compiler complains.

That's more of a feature. If you're passing something else this may well indicate a mistake.

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? 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.

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.