Re: [boost] [outcome] To variant, or not to variant?

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 
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 <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 :)

Cheers
- Asbjørn