MonadFail proposal (MFP): Moving fail out of Monad

[Herbert Valerio Riedel]

On 2015-06-10 at 00:42:12 +0200, David Luposchainsky wrote:

[...]

> I think there are two important consequences of MonadFail. First of all, we can
> all safely write failable patterns if we so desire. Second, the compiler can
> ensure other people's codebases do not lie to us (knowingly or unknowingly).

...as a data-point, when turning on MonadFail during testing, I've seen
at least one place in GHC's own code-base that directly calls 'fail' for
a Monad instance which did *not* have its 'fail' method
overridden. Moreover, I've seen at least one (other) case, where
failable pattern matches occurred (intentionally or not[1]), but the
respective Monad instance didn't have the 'fail' method overridden
either.

 [1]: Failable patterns can in theory snuck in non-intentionally,
      e.g. they can be introduced during refactoring if e.g. a
      single-constructor type gets added new constructors. If the
      context was previously constraint to a 'Monad', after the
      refactoring the typechecker would point out that now there's a
      failable pattern not accounted for.