You can find a short discussion/proposal on a rule that would do something in the same vein
I think you will have false positives (when you report an error but shouldn’t have) and false negatives (when you don’t report anything while you should have)
I think you need some kind of type inference to be able to detect these.
For instance, if you have
Maybe.withDefault identity maybeFunction == ...
Then you need to infer the type of the expression on the left to understand that it will result in a function. It’s possible, but not something I have been able to have built-in into elm-review at the moment.
Another false negative is that you need to understand when a function will try to compare things.
isEqual = (==)
a = isEqual b c
If b and c are or contain functions, then this should not be allowed. The places where isEqual is used should also be checked, in addition to all the places where == is used. Same thing for any function that does this equality check at any point in their code (directly or indirectly) where the types would allow the comparison of something that contains functions (meaning all functions except where from the type signature you can confirm the inputs won’t contain a function, or when you can determine that one of the == operands is not a function).
A third false negative, is that elm-review doesn’t look at the source code of dependencies, and without doing that, you can’t know whether a custom type (directly or indirectly) from a dependency, or a value from/containing that type, contains a function. We could if we knew whether the type was equatable or not though.
I can’t think of false positives off the top of my head, but I guess that detecting some true positives while never reporting a false positive could already be useful to prevent crashes.
I’m probably forgetting cases, and I haven’t looked at your code too much (don’t have access to a laptop at the moment), but this would be quite a complex rule to create.
This is typically a case where you’d want the type system to take care of this, because we want to make something impossible based on the type of a value, not based on how it’s written.
I’m looking forward to see the equatable type in the language! And I’m very curious to see how the documentation (and docs.json) would display it.