Closed MartinSStewart closed 4 years ago
I've started on a proof of concept for this idea using elm-script instead of elm-review for collecting Elm modules. My experience from working on this so far is that I think it is complicated enough that it's better to have as a stand alone tool rather than have it as an elm-review rule.
I think it makes sense then to close this issue.
Sure, let us know how that goes. I would love to know what (else) you would need in elm-review
to make this possible and easier.
What the rule should do: This rule checks if a function called
unreachableCase
really is unreachable. The function is defined asThe use for this is to avoid having to deal with type variants that should never occur. For example
This is essentially a generalization of https://jfmengels.net/safe-unsafe-operations-in-elm/
How I think this rule will work:
unreachableCase
function callcase...of
case...of
*. Here's a talk showing how that can be done https://www.youtube.com/watch?v=afMD-hkWPsQunreachableCase
then the rule passes, otherwise it fails.*Since we are running an interpreter, we can count how many steps we've taken and deterministically timeout to prevent getting caught in an endless loop. The deterministic part is important as it prevents this rule from passing on your dev machine and then failing during CI.
Example of things the rule would report:
Here the
unreachableCase
isn't inside a pattern match. While this situation probably could be handled, I don't see any value in supporting this.Here
longRunningComputation
will eventually returnJust
but it takes too many steps so the rule times out and fails.Example of things the rule would not report:
I am looking for: