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

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-15 16:20:30

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