Re: [boost] [outcome] outcome without empty state?

Subject: Re: [boost] [outcome] outcome without empty state?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-27 12:03:48

2017-05-27 2:12 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> >> Where I'm aiming, as you'll see in the summary design document I'll
> >> post shortly, is that the implicit conversion semantics will provide
> >> the ability to use a less representative variety to construct things,
> >> but return into a more representative variety.
> >
> > This holds in principle but I'm not sure that result<T> should convert
> > into the hypothetical result_e<T>. From the discussion so far, I got the
> > impression that we don't want to return empty results from functions; it
> > seems to follow that result_e<T> would not be a return type, but the
> > type of the local variable in the function that is initially empty but
> > eventually acquires either a value or an error before being returned as
> > result<T>.
>
> That certainly is one design choice. I definitely have functions in
> KernelTest and AFIO which would be returning a result_e<T> as the empty
> return is part of the function's public contract. I gave an example of
> such a function a few days ago.
>

Sorry, but the amount of threads to follow is getting difficult. Could you
point again to the example?

Regards,
&rzej;