Closed jmid closed 1 year ago
I'm happy to tackle this issue.
I see two ways of doing it:
shrink
argument, with default to the present value so that we don't beak backward compatibility, to Shrink.string
, string_gen_of_size
and string_gen
so that we can fix numeral_string
and the others string_gen_of_size_with_shrinker
and a string_gen_with_shrinker
that we will use in the functions we want to fix.1
is less code but modifies an existing signature in the api while 2
is more code but does not modify existing signature (we can decide whether to add the new ones or not).
What do you think?
While reviewing #245 I just realized that some of our
arbitrary string
generators inQCheck
may have surprising shrinking behavior. ForQCheck.numeral_string
this means that it may shrink to non-numeral strings:This is a consequence of how
string_gen
andstring_gen_of_size
falls back on a genericShrink.string
https://github.com/c-cube/qcheck/blob/fa6481fb3ecdc8fe4406ad95c883a136e4cf92f7/src/core/QCheck.ml#L1112-L1128Generators
numeral_string
andnumeral_string_of_size
are definitely affected. I suspect thatprintable_string
printable_string_of_size
, andsmall_printable_string
may also shrink to strings with non-printable characters under the right conditions.