Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-15 11:15:23
> I think Niall's choice is a practical one: if you must compromise the
> interface anyway on one or the other side of the function, at least
> optimize for performance: implementing the "empty" state comes for free.
It's definitely the case that internally you always need to have an
empty state unless you are using Anthony's Williams' double buffer
design to enable variants to never ever be empty.
But Outcome's API choice was based from the beginning on choosing a
ternary logic for the public API. I personally think it's a great fit
which is why I chose it, but I appreciate the majority thinks these
sorts of class ought to have binary state. Hence Expected's design.
As I mentioned to Peter, if you really hate the ternary logic, just
don't use the other state. Then you get boolean logic.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk