On 31.05.2017 10:26, Gavin Lambert via Boost wrote:
I probably should have thought of asking this earlier, but it occurs to me now that my own mental model of how an "outcome"-ish type should act is probably not suited to variant storage at all.
I'm just a plain C++ user, and my gut is leaning strongly towards the variant-like storage. However...
Perhaps this could even be exposed even more so that user code could explicitly provide both a value and an error -- think "here's a value, but it was truncated" or "here's the 5 values you asked for, but there's more", both fairly common in system APIs.
This sort of thing is very common in system APIs as you mention. So if outcome
is meant to be able to wrap those "directly" then clearly it needs to be able to
do both.
But for these "non-error error results", I think I would prefer the code
wrapping it in an outcome to put the non-error bits as part of the value. For
example, a "here's some data, but I got more" error code could be handled by
outcome's value storing a