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.

Environment

None

Assignee

gfredericks

Reporter

gfredericks

Labels

Approval

None

Patch

None

Priority

Major
Configure