Should we rename recover by catch_error? about expected HOT 9 CLOSED

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

from expected.

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.

from expected.

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

from expected.

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.

from expected.

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.

from expected.

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;

from expected.

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.

from expected.

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;

from expected.

4b62de9

from expected.