-
Notifications
You must be signed in to change notification settings - Fork 18
Should we rename recover by catch_error? #28
Comments
Not sure, "catch" really sounds exception-oriented but here it might not be. |
As we have |
Maybe but I don't like much the catch_exception as a member so I wouldn't pay too much attention about it. |
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. |
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. |
I have defined the Concerning the do notation, I have added it to the documentation removing the keyword return auto a <- f :
auto b <- g :
a + b; |
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. |
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; |
No description provided.
The text was updated successfully, but these errors were encountered: