Proposal: Delete IO#ensuring about cats-effect HOT 4 CLOSED

Alright, I'll PR ensuring (probably under some other name) to ApplicativeError in cats-core. Once that's in, I'll remove it here.

On the broader topic of discoverability vs implicits… I think that's a dichotomy that we should really figure out how to solve in the tooling layer, and trying to contort our implementations to resolve it seems… incorrect. So whenever it makes sense, removing stuff from IO and letting the typelcasses do the heavy lifting should be our policy. The exceptions should be primarily in the areas of efficiency (i.e. where we can get a better-than-default implementation by specializing). If we specialize a function, we can just put it concretely on IO and delegate from the typeclass instance.

from cats-effect.

If the intent is to keep IO minimal, delegating its functionality to Cats' type-classes, then yes, it makes sense to push that into MonadError.

from cats-effect.

At the risk of widening this discussion, I'd like to come to a consensus on "keep IO minimal and teach everyone to import cats.implicits._" vs. "make a more discoverable IO and be sad about the redundancies."

from cats-effect.

I think that import cats.implicits._ is fine, because this is meant to be deeply integrated into and piggyback on Cats.

I'm a little selfish, but the reason for why I want this is because I feel that Cats has missing type-classes, or type-classes with incorrectly used operations and pushing more responsability on Cats' type-classes will make Cats-core better.

For example I discovered that ApplicativeError.catchNonFatal is not being overridden for type-classes that might implement it lazily, like in cats.Eval, making it next to useless, even though it is being promoted as a lazy Applicative.pure.

from cats-effect.