Le 21/06/15 09:07, Vicente J. Botet Escriba a écrit :
Le 19/06/15 19:03, Niall Douglas a écrit :
Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>.
A few additional questions: * The future::then function has the semantic of calling the continuation when the future becomes ready. In addition the future::then moved the future to the continuation. I believe that your monad<T>::then has not this semantic. So, what is the added value of this function? IIUC, the difference between m.then(f); and f(m); is that monad::then wraps the result of f if needed as bind do, but the continuation function takes a monad reference I believe that it would be better to have a different name. What a bout next, wrap_call, call_with, ...? * As you have bind, why you don't have catch_error? I understand that ::then could be used instead, but I would add it just for symmetry and because the user don't needs to check when she is handling errors. * What about having a match function using overload on the stored type? [1] * Monads are defined by having a bind and unit functions. I'm missing a unit function. std::future has std::make_future_ready, expected has make_expected, std::optional has std::make_optional. I've been working on a generic make factory library [2] that could be associated to the unit Monad function Vicente [1] https://github.com/viboes/tags/tree/master/doc/proposals/match [2] https://github.com/viboes/std-make/tree/master/doc/proposal/factories