Subject: Re: [boost] [outcome] To variant, or not to variant?
From: AsbjÃ¸rn (lordcrc_at_[hidden])
Date: 2017-05-31 11:26:59
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
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 <value_t, bool> tuple or similar rather than just value_t.
A truncated output has always been a proper error in my world, and handled as
such (fex retrying after increasing buffer).
Then again, just a plain user so :)