Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at