Proposal to deprecate and then drop fromJust

Richard Eisenberg eir at
Tue Feb 24 15:01:35 UTC 2015

I've been wanting to get warnings on partial functions (and partial record accessors, while we're at it!) for some time.

And, I think it would be quite easy to have GHC infer partiality. As far as I can see, partiality can come from only two places: the use of a partial function, and an incomplete pattern match. (I'm ignoring nontermination here, which I think is best considered separately.) Before getting this into GHC, though, we'd need to make sure the incomplete-pattern-match checker is up for it (see #3927), but that work is being done right now. And we'd definitely need a way for users to declare "This function is total! Really!"

I like the idea of user-specified warning categories, but I think partiality is easy enough for GHC to infer that it should be built in.

+1 on partiality warnings, preferably inferred
+0.8 on user-specified warning classes (but inferred partiality is my preference)

-0.9 on just attaching a one-off warning to fromJust (we can do so much better)
-1 on removing fromJust (I use it myself [don't hate me for it], and the GHC codebase uses `expectJust`, which takes a string for better error messages, 54 times by my count)


On Feb 24, 2015, at 7:28 AM, Herbert Valerio Riedel <hvr at> wrote:

> On 2015-02-24 at 12:32:14 +0100, Michael Snoyman wrote:
>> We could also automatically detect basic partiality, like incomplete
>> pattern matches, and add partiality warnings. Depending on how much work
>> that is, it may be easier than trying to mark up all of base
>> correctly.
> You'd still need a way to greenlight false positives. I.e. cases where
> the code *seems* to have unhandled pattern matches which can't happen,
> but which GHC can't prove them not to be unhandled...
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list