add abilitity to instantiate a non-blocking Future from MonadError

[kevinschmidt]

When abstracting functions to return MonadError, to use Future in production and Try in unit testing, it's impossible to get an async Future from any function of the Future implementation of MonadError - either Future.successful or Future.failed is called.

In cats versions before 0.7.x. Monad.pureEval would call Future.apply, as this function was removed, there is no way to use either MonadError or Monad in an abstract way to create an async Future, which makes it hard to wrap synchronised code blocks (e.g. Java, etc.) into abstract Monads.

I would expect MonadError.catchNonFatal to show this behaviour but it's implemented as try pure(a) catch {...} (in ApplicativeError) calling Future.successful. @alexknvl suggested on Gitter to specialise this function in FutureInstances as:

def catchNonFatal[A](a: => A)(implicit ev: Throwable <:< E): Future[A] = Future.apply(a)

This would makes sense to me. This issue is probably related to #1316.

[johnynek]

I think the override you suggest is correct in any case. Can you send a PR? About the need to run an effectful computation, let's stay on #1316. I advocate taking a FunctionK[Eval, M] along with Monad[M] personally, when you need that.

…

On Sat, Dec 3, 2016 at 05:07 Kevin Schmidt ***@***.***> wrote: When abstracting functions to return MonadError, to use Future in production and Try in unit testing, it's impossible to get an async Future from any function of the Future implementation of MonadError - either Future.successful or Future.failed is called. In cats versions before 0.7.x. Monad.pureEval would call Future.apply, as this function was removed, there is no way to use either MonadError or Monad in an abstract way to create an async Future, which makes it hard to wrap synchronised code blocks (e.g. Java, etc.) into abstract Monads. I would expect MonadError.catchNonFatal to show this behaviour but it's implemented as try pure(a) catch {...} (in ApplicativeError) calling Future.successful. @alexknvl <https://github.com/alexknvl> suggested on Gitter to specialise this function in FutureInstances as: def catchNonFatal[A](a: => A)(implicit ev: Throwable <:< E): Future[A] = Future.apply(a) This would makes sense to me. This issue is probably related to #1316 <#1316>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1482>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJdqNEFkNkcARnJBc39UvpkElWUR1Vks5rEYWWgaJpZM4LDUVU> .

[kevinschmidt]

Sounds good, will sent a PR.

[johnynek]

@kevinschmidt I made #1510 so we can address this for 0.9.0. Does this look fine?

[kevinschmidt]

@johnynek looks good! thx!