2017-05-27 2:12 GMT+02:00 Niall Douglas via Boost
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;