Should we rename recover by catch_error?

[ptal]

Not sure, "catch" really sounds exception-oriented but here it might not be.

[viboes]

As we have catch_exception that is used also to recover from exception, it seems that recover is to general, and cath_error is more specific.

[ptal]

Maybe but I don't like much the catch_exception as a member so I wouldn't pay too much attention about it.

[viboes]

My intention, once we have the monads interface is to remove the definition of the all the functions that can be implemented using the minimal interface. Thus, catch_error, catch_exception, mbind, ... all of them could be removed from the expected interface.

I think that this is the basic idea of splitting Algorithm and Data Structures.

[ptal]

Ok, I didn't know you wanted to remove that from the interface. But it's right and it's the spirit of the C++ STL. However I'm afraid we'll lose some conveniences without the chaining. Hopefully a binary operator (such as the previously proposed |>) or a construction similar to the do notation would simplify this a lot. Now that I understand your point, I'm ok with the name.

[viboes]

I have defined the operator &() for mbind and operator |() for catch_error on monads errors. These operators allows to chain as if we used the haskell operators >>= and 'catch_error'

Concerning the do notation, I have added it to the documentation removing the keyword expect.

return auto a <- f :
       auto b <- g : 
       a + b;

[ptal]

Ok nice, could we extend this to:

auto x = auto a <- f :
         auto b <- g : 
         a + b;

So it could appear outside a return statement.

[viboes]

The return statement is not part of the do-expression. This was an example. You could even do the following

auto x = (auto a <- f :
          auto b <- g : 
          a + b)
        | recoverHandler;

[viboes]

https://github.com/ptal/Boost.Expected/commit/4b62de96dc1a751b01a1e2230244b776dc47e323