ApplicativeError's orElse should accept widening?

[sarahgerweck]

With the exception of the new (as of Cats 1.2) orElse in ApplicativeError, most other places (including in the Cats library) that have an orElse allow the widening of its second parameter.

The traditional signature of an orElse for ApplicativeError would be

def orElse[AA >: A](other: ⇒ F[AA])(implicit F: ApplicativeError[F, E]): F[AA]

This is currently preventing me from upgrading to Cats 1.2, because my own orElse is no longer being picked up. I don't find any discussion of using this uncommonly restrictive signature in #2243: was this just an accidental oversight. I wanted to trigger the discussion about whether the Cats signature was wrong before I go work around this in my own code.

I'm not sure if this change can be made without breaking binary compatibility, but I can submit a PR if there's interest. I think the current signature is undesirable.

[kailuowang]

It is inconsistent with orElse in other places and a bit inconvenient, but it's consistent with all the other error handling methods in ApplicativeError.
That being said, I am not against the change you are proposing. I believe such a change is binary compatible (tested with mima). Not 100% sure if it's going to be source compatible though - if F is contravariant, the return type might change from F[A] to F[AA] when a F[AA] is passed in. Since F[AA] is a subtype of F[A] it might be very rare that a user would need to modify usage.
I'd like to hear what other maintainers think.

There are two alternatives to making such a change:

1. change your usages to fa.widen[AA].orElse(other).
2. create a def orElseW[AA >: A]

[johnynek]

I think all applicatives are covariant (since they are Functors and all functors are)

If this is compatible I’m for it.