Well, still one more thing. I mean, not a big thing, and as you mentioned, it’s not something you really have to learn since it guides you to use it when needed, but my point is: why having this “one more thing” if we could make what we already have (the docs) dynamic to solve the problem?
Sorry if it was not clear. The function accepted in my example would either be a 0 or 1 arity function, and for 1-arity function it would receive the values of arguments. This could be used to make h Math.div(1, 0) print out some help about division by zero.
I mean, I know it may not be used that much, but still, it’s an improvement to the docs that makes it possible to do what you want for guards. Also, I know it creates problems to generate the online docs, since there will be multiple versions of it for the same function, but we could define that this 1-arity functions should always match to nil and print the details for all cases there, and send nil as this function when generating the online docs or when doing h Math.div.
Something like this:
defmodule Math do
@doc &div_doc/1
def div(left, right), do: left / right
defp div_doc([_, 0]), do: "It's mathematically impossible to divide any number by `0`"
defp div_doc(nil) do
"""
Divides `left` by `right`
## Observations
- `right` should not be `0`: #{div_doc([nil, 0])}
"""
end
end
EDIT: I know the example I created is not very good use case for this 1-arity function, and I really can’t think on a good one for it right now. So maybe only supporting 0-arity functions would be good enough, since it already covers everything you would be able to do with help catalogs, and we could leave the h Math.div(x, y) idea for another time. 
