Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk