Consider whether the tweaked semantics of the :result key should be reserved for quick-check-2
Description
Given the current state of the master branch, a library digesting the return value from quick-check will need to do some acrobatics to tell whether the property threw an exception, since old versions indicate it one way and new versions indicate it differently.
In particular:
Result | :result before | :result after | :result-data after |
|---|---|---|---|
Success | true | true | (not present) |
Failure | false | false or user object | user supplied data |
Exception | the exception | ErrorResult object | map including the exception |
This means any 3rd-party library that wants to determine compatibly whether a return map from quick-check represents a success or failure will need to have even more conditionals than before. In particular it will need to (at compile time?) determine if the results/Result protocol exists, and if so examine the :result object on that basis, otherwise using the "is it a Throwable or not?" codepath.
An alternative that only adds new keys instead of changing the meaning of old keys:
Still allow users to return custom impls of the Result protocol, but translate them back into true/false/Throwable for the :result key. Add a new :result-data key that has a :clojure.test.check/passing? nested key, and :clojure.test.check/error as well if applicable.
