Deprecation Reversal about elm-check

[mgold]

This project was the direct inspiration for elm-test fuzzing, so I'm confused as to how it would be "anywhere near as powerful". This library has some major disadvantages, such as the reliance on backticks that are no longer in the language, weird types and bad error messages, and the immediate execution of tests (elm-test uses functions to allow for parallelization).

We also found that it is helpful to separate the creation of randomized, shrinkable values (fuzzing) from making assertions about them -- so that the same assertions can be used in unit tests. Meanwhile, we also found it helpful to keep both functionalities in one library: rather than an awkward add-on to elm-test, fuzzers are built right in.

Do you have some examples of what you think this library can do that elm-test cannot? We are always willing to consider good ideas that could potentially be incorporated into elm-test.

[Qata]

Fuzz has no concept of being able to permanently filter a producer, and the documentation for conditional states that if you use an arbitrarily large amount of retries then it may blow the stack. This is very limiting and represents most of why I cannot use Fuzz for my own purposes.
If it was updated to include a true filter then it would reach feature parity with this library.

[mgold]

Filtering was added, and removed, because it caused infinite looping when most of the values were filtered out. See discussion here among other places. You should find a more clever way to generate the data you need without filtering the fuzzer. I've had a similar issue, and solution, with Scala-check (which does have a filter function), so the issue is not unique to Elm or elm-test: filtering an infinite stream until you have n items is simply a bad situation best avoided.