Ok so the approach is to do auto expected1 = do_statement1(); if (!expected1) return expected1; auto expected1_value = expected1.value(); auto expected2 = do_statement2(expected1_value); if (!expected2) return expected2; auto expected2_value = expected2.value(); return do_statement3(expected2_value); with that logic being encoded by the TRY macros? I'd rather use continuation passing style, was that considered? return expected_flow(do_statement1)
[](auto const& expected1_value) { return do_statement2(expected1_value); } [](auto const& expected2_value) { return do_statement3(expected2_value); } ;
On 1 June 2017 at 10:44, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
2017-06-01 11:12 GMT+02:00 Mathias Gaunard via Boost < boost@lists.boost.org> :
Hi,
I just took a quick look at outcome today and I don't really understand what it is doing.
I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad. I searched throughout the documentation and didn't find any.
Why is there no example of this? More than how the error state is captured and stored or how to capture custom errors, I believe the programming model is what the tutorial should really focus on.
It has been agreed upon that the tutorial needs to undergo a rewrite. Meanwhile, maybe the following examples can help:
https://github.com/akrzemi1/__sandbox__/blob/master/outcome_intro2.md https://github.com/akrzemi1/__sandbox__/blob/master/outcome_ practical_example.md
Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost