|
Boost : |
Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-20 18:01:10
> I am not trying to propose any new logic here. I am trying to assign some
> mental model to what `outcome<T>` currently does. Consider: some funciton
> `f` is supposed to compute an `int`. But the computation may fail, in this
> case I want the function to return the reason why it failed. Also, it is
> possible that I will get some "internal error". For this reason funcio `f`
> returns `result<T>`:
>
> ```
> result<T> r = f();
> ```
> Now, `r` can represent the following states:
>
> ```
> if (r.has_value()) // value successfully computed
> {}
No, the correct interpretation here is that the result returned has a
value, not that the value was successfully computed.
> else if (r.empty()) // internal error
> {}
> else if (r.error()) // reason why f failed
> {}
> else if (r.has_error() && !r.error()) // what is that???
> {}
Similarly to the value returned case, Outcome does not involve itself
into whether a T value returned is valid or not in exactly the same way
as it does not involve itself into whether a E value returned is valid
or not.
> The last case is neither a value, nor a reason for failure, nor an
> "internal error". How should a caller interpret it? Two possible answers:
>
> 1. There is a fourth state with no intuitive or sane interpretation.
> 2. Assume this never happens. If it happens it is a bug in calle site that
> needs to be fixed.
You've got to remember all these potential state flow paths never occur
in any real world code base. You'll even see the compiler eliding in the
assembler output any handling of an empty state being returned if it can
see that that is not possible.
Same goes for if you return only ever a value. The result<T> effectively
"disappears" in the assembler generated, and it is as if you returned a
T directly.
Niall
-- 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